Hi,
I'd like to write a windows app that accesses a locally stored database.
There are a number of tables, the largest of which has 455,905 records.
Can anyone recommend a database that runs on Windows, is fast /
efficient and can be shipped without restrictions or extra downloads?
I have googled and found plenty of information on databases, its just
that I dont have enough experience with databases to know which one is
best for my task!
Thanks in advance,
Will McGugan
-- http://www.willmcgugan.com
"".join({'*':'@','^':'.'}.get(c,0) or chr(97+(ord(c)-84)%26) for c in
"jvyy*jvyyzpthtna^pbz") 33 1926
"Will McGugan" <ne**@NOwillmcguganSPAM.com> wrote in message
news:42***********************@news.zen.co.uk... Hi,
I'd like to write a windows app that accesses a locally stored database. There are a number of tables, the largest of which has 455,905 records.
Can anyone recommend a database that runs on Windows, is fast / efficient and can be shipped without restrictions or extra downloads?
I have googled and found plenty of information on databases, its just that I dont have enough experience with databases to know which one is best for my task!
If you are writing strictly for the MS Windows platform
And
If the database is running single user with a "locally stored database" on a
Windows workstation.
Then
The MS Access file based (.mdb) system is hard to argue with.
You wouldn't have to distribute the (rather expensive) Access application
since this is little more than a front for the underlying DAO/ADO database
libraries that are built into the warp and woof of MS Windows. Your Python
application can address the DAO or ADO directly as these will libraries will
be pre-installed and/or freely available for MS Windows. Fast, freely
available, no license restrictions, and no need for extra downloads for a
reasonably recent (Win2000, XP) operating system.
On the other hand, if operating system portability were a concern (as it
should be!), I might suggest MySQL.
A Python/MySQL application can jump between Windows to Linux (all flavors!)
to Unix to BSD without need to alter a single line of code.
You were writing a Python app, weren't you :-)
Thomas Bartkus
I always figured a problem with using MySQL was distribution. Would
you have to tell your users to install MySQL and then to leave the
service running? I've never found an easy way to embed MySQL into a
python app, and even if you could, would you then have to pay for it?
-Greg
On 6/22/05, Thomas Bartkus <th***********@comcast.net> wrote: "Will McGugan" <ne**@NOwillmcguganSPAM.com> wrote in message news:42***********************@news.zen.co.uk... Hi,
I'd like to write a windows app that accesses a locally stored database.. There are a number of tables, the largest of which has 455,905 records.
Can anyone recommend a database that runs on Windows, is fast / efficient and can be shipped without restrictions or extra downloads?
I have googled and found plenty of information on databases, its just that I dont have enough experience with databases to know which one is best for my task! If you are writing strictly for the MS Windows platform And If the database is running single user with a "locally stored database" on a Windows workstation. Then The MS Access file based (.mdb) system is hard to argue with. You wouldn't have to distribute the (rather expensive) Access application since this is little more than a front for the underlying DAO/ADO database libraries that are built into the warp and woof of MS Windows. Your Python application can address the DAO or ADO directly as these will libraries will be pre-installed and/or freely available for MS Windows. Fast, freely available, no license restrictions, and no need for extra downloads for a reasonably recent (Win2000, XP) operating system. On the other hand, if operating system portability were a concern (as it should be!), I might suggest MySQL. A Python/MySQL application can jump between Windows to Linux (all flavors!) to Unix to BSD without need to alter a single line of code. You were writing a Python app, weren't you :-) Thomas Bartkus -- http://mail.python.org/mailman/listinfo/python-list
Take a look at Firebird. It can be run in embedded mode. It might be
overkill for your needs though...
On 6/22/2005 10:37 AM, Gregory Piñero wrote: I always figured a problem with using MySQL was distribution. Would you have to tell your users to install MySQL and then to leave the service running? I've never found an easy way to embed MySQL into a python app, and even if you could, would you then have to pay for it?
-Greg
On 6/22/05, Thomas Bartkus <th***********@comcast.net> wrote:
"Will McGugan" <ne**@NOwillmcguganSPAM.com> wrote in message news:42***********************@news.zen.co.uk. ..
Hi,
I'd like to write a windows app that accesses a locally stored database. There are a number of tables, the largest of which has 455,905 records.
Can anyone recommend a database that runs on Windows, is fast / efficient and can be shipped without restrictions or extra downloads?
I have googled and found plenty of information on databases, its just that I dont have enough experience with databases to know which one is best for my task!
If you are writing strictly for the MS Windows platform And If the database is running single user with a "locally stored database" on a Windows workstation. Then The MS Access file based (.mdb) system is hard to argue with. You wouldn't have to distribute the (rather expensive) Access application since this is little more than a front for the underlying DAO/ADO database libraries that are built into the warp and woof of MS Windows. Your Python application can address the DAO or ADO directly as these will libraries will be pre-installed and/or freely available for MS Windows. Fast, freely available, no license restrictions, and no need for extra downloads for a reasonably recent (Win2000, XP) operating system.
On the other hand, if operating system portability were a concern (as it should be!), I might suggest MySQL. A Python/MySQL application can jump between Windows to Linux (all flavors!) to Unix to BSD without need to alter a single line of code.
You were writing a Python app, weren't you :-) Thomas Bartkus
-- http://mail.python.org/mailman/listinfo/python-list
On 2005-06-22, Will McGugan <ne**@NOwillmcguganSPAM.com> wrote: I'd like to write a windows app that accesses a locally stored database. There are a number of tables, the largest of which has 455,905 records.
Can anyone recommend a database that runs on Windows, is fast / efficient and can be shipped without restrictions or extra downloads? http://pysqlite.org
Dave Cook
Will McGugan wrote: Hi,
I'd like to write a windows app that accesses a locally stored database. There are a number of tables, the largest of which has 455,905 records.
Can anyone recommend a database that runs on Windows, is fast / efficient and can be shipped without restrictions or extra downloads?
I have googled and found plenty of information on databases, its just that I dont have enough experience with databases to know which one is best for my task!
Neither do we, considering that brief description.
Will there be multiple simultaneous users?
Multiple simultaneous writers?
Do you require proper transaction management?
(Or is it a pure read-only database, since you know
exactly how many records the largest table has?)
Do you need to make ad-hoc queries?
What will your code look like?
* Is it object-oriented?
* Are there a lot of fixed relations between objects?
Are there other requirements such as need for undo or
change history management?
Does the application work with small chunks of data at a time
(such as in a ticket ordering system) or with larger chunks
(such as in a web site CMS)?
What size is it? It's a big difference between 455,905 integers
and 455,905 mp3 files for instance...
"A number of tables" tells us very little, more than suggesting
that it's more than one... Ten and 200 makes a big difference.
Thomas Bartkus wrote: If you are writing strictly for the MS Windows platform And If the database is running single user with a "locally stored database" on a Windows workstation. Then The MS Access file based (.mdb) system is hard to argue with.
I disagree. What does .mdb/jet without Access offer you that you
don't get from e.g. SQLite except vendor lock-in and horrible
deviations from the SQL standard? Ok, it does give you somewhat
stronger typing, which you might possibly want, but if that's
an issue, I'd suggest embedded firebird (if we want serverless).
I'm not entirely sure something SQLish is the way to go though.
Also, the best ODBC adaper for Python, mxODBC, isn't free. Last
time I used adodbapi, it was a bit buggy, and pure ADO or DAO
solutions don't follow the Python standard DB-API 2.
Will McGugan" <ne**@NOwillmcguganSPAM.com> wrote in message
news:42***********************@news.zen.co.uk... Hi,
I'd like to write a windows app that accesses a locally stored database. There are a number of tables, the largest of which has 455,905 records.
Can anyone recommend a database that runs on Windows, is fast / efficient and can be shipped without restrictions or extra downloads?
I have googled and found plenty of information on databases, its just that I dont have enough experience with databases to know which one is best for my task!
If you are writing strictly for the MS Windows platform
And
If the database is running single user with a "locally stored database" on a
Windows workstation.
Then
The MS Access file based (.mdb) system is hard to argue with.
You wouldn't have to distribute the (rather expensive) Access application
since this is little more than a front for the underlying DAO/ADO database
libraries that are built into the warp and woof of MS Windows. Your Python
application can address the DAO or ADO directly as these will libraries will
be pre-installed and/or freely available for MS Windows. Fast, freely
available, no license restrictions, and no need for extra downloads for a
reasonably recent (Win2000, XP) operating system.
On the other hand, if operating system portability were a concern (as it
should be!), I might suggest MySQL.
A Python/MySQL application can jump between Windows to Linux (all flavors!)
to Unix to BSD without need to alter a single line of code.
You were writing a Python app, weren't you :-)
Thomas Bartkus
On 6/22/2005 11:38 AM, Thomas Bartkus wrote: Will McGugan" <ne**@NOwillmcguganSPAM.com> wrote in message news:42***********************@news.zen.co.uk...
Hi,
I'd like to write a windows app that accesses a locally stored database. There are a number of tables, the largest of which has 455,905 records.
Can anyone recommend a database that runs on Windows, is fast / efficient and can be shipped without restrictions or extra downloads?
I have googled and found plenty of information on databases, its just that I dont have enough experience with databases to know which one is best for my task!
If you are writing strictly for the MS Windows platform And If the database is running single user with a "locally stored database" on a Windows workstation. Then The MS Access file based (.mdb) system is hard to argue with. You wouldn't have to distribute the (rather expensive) Access application since this is little more than a front for the underlying DAO/ADO database libraries that are built into the warp and woof of MS Windows. Your Python application can address the DAO or ADO directly as these will libraries will be pre-installed and/or freely available for MS Windows. Fast, freely available, no license restrictions, and no need for extra downloads for a reasonably recent (Win2000, XP) operating system.
And then XP Autoupdate executes, some of those Access/MSDE libraries are
updated, and you app is broken.
"Dan" <da*@nospam.com> wrote in message
news:UJ***************@news.uswest.net... On 6/22/2005 11:38 AM, Thomas Bartkus wrote: Will McGugan" <ne**@NOwillmcguganSPAM.com> wrote in message news:42***********************@news.zen.co.uk...
And then XP Autoupdate executes, some of those Access/MSDE libraries are updated, and you app is broken.
Hasn't happened yet!
For the record - I wouldn't recommend automatic updates of any kind for a
Linux/MySQL system either. For precisely the same reasons.
Thomas Bartkus
Gregory Piñero wrote: I always figured a problem with using MySQL was distribution. Would you have to tell your users to install MySQL and then to leave the service running? I've never found an easy way to embed MySQL into a python app, and even if you could, would you then have to pay for it?
There are more reasons than that not to use MySQL...
See e.g. http://sql-info.de/mysql/gotchas.html
It seems a lot of the most badly missed features are
appearing in MySQL 5.0, but as features are added, I
suppose the claimed advantages in performance and
simplicity withers away, and these features can hardly
be considered very mature yet. (One should also note
that MySQL manuals have often claimed that features
it lacked were useless, or even dangerous, until
MySQL AB decided to implement them themselves... :)
Also, the GPL/Commercial licence is not a good thing
for commercial apps, particularly since this licence
applies even to client libs.
Recent PostgreSQL versions are stable, fast, and have
native Windows versions.
In article <UJ***************@news.uswest.net>, Dan <da*@nospam.com> wrote:
On 2005-06-22, Cameron Laird <cl****@lairds.us> wrote: Are you saying that Python-based applications are particularly vulnerable in this all-too-common scenario? If so, I'm not getting it; why is the architecture described more fragile than more traditional Windows-oriented development patterns? If not, then, ... well then I truly don't get your point.
Maybe the point is the downside of depending on installed DLLs rather than
shipping your own.
Dave Cook
On 6/22/2005 1:14 PM, Dave Cook wrote: On 2005-06-22, Cameron Laird <cl****@lairds.us> wrote:
Are you saying that Python-based applications are particularly vulnerable in this all-too-common scenario? If so, I'm not getting it; why is the architecture described more fragile than more traditional Windows-oriented development patterns? If not, then, ... well then I truly don't get your point.
Maybe the point is the downside of depending on installed DLLs rather than shipping your own.
Dave Cook
Yes, DLL hell.
At 3:14 PM +0100 6/22/05, Will McGugan wrote: Hi,
I'd like to write a windows app that accesses a locally stored database. There are a number of tables, the largest of which has 455,905 records.
Can anyone recommend a database that runs on Windows, is fast / efficient and can be shipped without restrictions or extra downloads?
I have googled and found plenty of information on databases, its just that I dont have enough experience with databases to know which one is best for my task!
Thanks in advance,
Will McGugan
We use Firebird for that.
<http://www.firebirdsql.org>
--Ray
--
Raymond Cote
Appropriate Solutions, Inc.
PO Box 458 ~ Peterborough, NH 03458-0458
Phone: 603.924.6079 ~ Fax: 603.924.8668
rgacote(at)AppropriateSolutions.com www.AppropriateSolutions.com
In article <3t***************@news.uswest.net>, Dan <da*@nospam.com> wrote: On 6/22/2005 1:14 PM, Dave Cook wrote: On 2005-06-22, Cameron Laird <cl****@lairds.us> wrote:
Are you saying that Python-based applications are particularly vulnerable in this all-too-common scenario? If so, I'm not getting it; why is the architecture described more fragile than more traditional Windows-oriented development patterns? If not, then, ... well then I truly don't get your point.
Maybe the point is the downside of depending on installed DLLs rather than shipping your own.
Dave Cook
Yes, DLL hell.
?
OK, I'm with you part of the way. Typical "Access" developers
are *always* involved with DLL hell, right? You're surely not
saying that Python worsens that frustration, are you?
Thanks for the replies. I think I'm going to go with sqllite for now.
For the curious, Im writing an interface to a nutritional database. So
you can type in a foodstuff and it will tell you whats in it..
Will McGugan
-- http://www.willmcgugan.com
"".join({'*':'@','^':'.'}.get(c,0) or chr(97+(ord(c)-84)%26) for c in
"jvyy*jvyyzpthtna^pbz")
Will McGugan wrote: Thanks for the replies. I think I'm going to go with sqllite for now.
Your list didn't mention a few things that might be critical.
Referential integrity? Type checking? SQLite currently supports
neither. Just make sure you check the list of supported features to see
that it really does what you need.
-Peter
On Wed, 22 Jun 2005 10:07:12 -0500, "Thomas Bartkus"
<th***********@comcast.net> declaimed the following in comp.lang.python: The MS Access file based (.mdb) system is hard to argue with. You wouldn't have to distribute the (rather expensive) Access application since this is little more than a front for the underlying DAO/ADO database libraries that are built into the warp and woof of MS Windows. Your Python
The RDBM engine, used by Access, has the name JET... so more
formally, it is the JET libraries that handle .mdb files. Newer versions
of Access also are designed to handle M$ SQL Server/MSDE as "Access
Projects". On the other hand, if operating system portability were a concern (as it should be!), I might suggest MySQL. A Python/MySQL application can jump between Windows to Linux (all flavors!) to Unix to BSD without need to alter a single line of code.
Firebird might be a contender... Or if someone ever released a
version of MySQLdb built against the embedded library (so no separate
server is needed -- I suspect distribution licenses get in the way of
that)
-- ================================================== ============ < wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG < wu******@dm.net | Bestiaria Support Staff < ================================================== ============ < Home Page: <http://www.dm.net/~wulfraed/> < Overflow Page: <http://wlfraed.home.netcom.com/> <
On Wed, 22 Jun 2005 19:21:37 +0200, Magnus Lycka <ly***@carmen.se>
declaimed the following in comp.lang.python: It seems a lot of the most badly missed features are appearing in MySQL 5.0, but as features are added, I suppose the claimed advantages in performance and simplicity withers away, and these features can hardly be considered very mature yet. (One should also note that MySQL manuals have often claimed that features it lacked were useless, or even dangerous, until MySQL AB decided to implement them themselves... :)
Might depend on how much is purely new code, and how much might
be purloined from the former SAP-DB (now "MaxDB by MySQL"), since a lot
of those features probably existed in the latter.
-- ================================================== ============ < wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG < wu******@dm.net | Bestiaria Support Staff < ================================================== ============ < Home Page: <http://www.dm.net/~wulfraed/> < Overflow Page: <http://wlfraed.home.netcom.com/> <
On 2005-06-23, Peter Hansen <pe***@engcorp.com> wrote: Your list didn't mention a few things that might be critical. Referential integrity?
You can implement it in sqlite with triggers. I only bother with cascading
delete triggers, myself.
Type checking? SQLite currently supports neither.
sqlite3 has a "strict affinity" mode, but I'm not exactly sure how one sets
it. http://www.sqlite.org/datatype3.html
Dave Cook
Dave Cook <da******@nowhere.net> writes: On 2005-06-22, Will McGugan <ne**@NOwillmcguganSPAM.com> wrote:
[...] Can anyone recommend a database that runs on Windows, is fast / efficient and can be shipped without restrictions or extra downloads?
http://pysqlite.org
Or APSW <http://www.rogerbinns.com/apsw.html>.
--
Joel Rosdahl <jo**@rosdahl.net>
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D 8B22 0064 F9FF BB84 5E97
Cameron Laird wrote: OK, I'm with you part of the way. Typical "Access" developers are *always* involved with DLL hell, right? You're surely not saying that Python worsens that frustration, are you?
I think Dan was commenting on flaws in Microsoft's products,
not in Python. As I understand it, he was suggesting to use
something else than Access with Python, not something else
than Python with Access. The O.P. wanted a database for his
Python app, and Thomas Bartkus suggested Access.
On 2005-06-23, Joel Rosdahl <jo**@rosdahl.net> wrote: Or APSW <http://www.rogerbinns.com/apsw.html>.
Interesting. I was hoping it would not have one pysqlite2 limitation: if
you have an empty database, cursor.description always returns None, even if
you have "pragma empty_result_callbacks=1" (pysqlite 1.x doesn't have the
problem). But apsw also requires data to be avaliable before you can get
column descriptions.
However, the tracing stuff and the various hooks you can set look really
interesting.
Dave Cook
Dennis Lee Bieber wrote: Firebird might be a contender...
I recently completed a 5 user Java based Windows reporting
system that used Firebird as the SQL server based database.
I found Firebird performed very well and I would not hesitate
to use it again.
Jussi Jumppanen
Author of: Zeus for Windows Editor (New version 3.94 out now)
"The C/C++, Cobol, Java, HTML, Python, PHP, Perl folding editor"
Home Page: http://www.zeusedit.com
"Magnus Lycka" <ly***@carmen.se> wrote in message
news:d9**********@wake.carmen.se... Cameron Laird wrote: OK, I'm with you part of the way. Typical "Access" developers are *always* involved with DLL hell, right? You're surely not saying that Python worsens that frustration, are you? I think Dan was commenting on flaws in Microsoft's products, not in Python. As I understand it, he was suggesting to use something else than Access with Python, not something else than Python with Access.
The O.P. wanted a database for his Python app, and Thomas Bartkus suggested Access.
Not exactly!
I suggested the built in Microsoft DAO or ADO database libraries which he
could use without need to distribute with his app. The Access application
is simply another client app that sits on top of DAO/ADO and would be quite
unnecessary here. Any Python/DB application you wished to distribute for MS
Windows would do best talk to the ADO library directly - end of distribution
problems.
* Everyone with WindowsXP already has the DAO and ADO libraries.
* Not everyone has (or needs) MS Access which one would have to pay for and
could not distribute freely with ones Python app.
* Python has no need of MS Access in order to create, maintain, and
manipulate databases using Microsofts built in ADO database facilities -
although a developer *might* find Access useful as an inspection/debugging
tool on his own workstation.
All of which used to confuse the hell out of me :-)
Thomas Bartkus
In article <sl*********************@localhost.localdomain>,
Dave Cook <da******@nowhere.net> wrote: On 2005-06-23, Peter Hansen <pe***@engcorp.com> wrote:
"Magnus Lycka" <ly***@carmen.se> wrote in message
news:d9**********@wake.carmen.se... Cameron Laird wrote: OK, I'm with you part of the way. Typical "Access" developers are *always* involved with DLL hell, right? You're surely not saying that Python worsens that frustration, are you?
I think Dan was commenting on flaws in Microsoft's products, not in Python. As I understand it, he was suggesting to use something else than Access with Python, not something else than Python with Access. The O.P. wanted a database for his Python app, and Thomas Bartkus suggested Access.
Not exactly!
I suggested the built in Microsoft DAO or ADO database libraries which he
could use without need to distribute with his app. The Access application
is simply another client app that sits on top of DAO/ADO and would be quite
unnecessary here. Any Python/DB application you wished to distribute for MS
Windows would do best talk to the ADO library directly - end of distribution
problems.
* Everyone with WindowsXP already has the DAO and ADO libraries.
* Not everyone has (or needs) MS Access which one would have to pay for and
could not distribute freely with ones Python app.
* Python has no need of MS Access in order to create, maintain, and
manipulate databases using Microsofts built in ADO database facilities -
although a developer *might* find Access useful as an inspection/debugging
tool on his own workstation.
All of which used to confuse the hell out of me :-)
Thomas Bartkus
Thomas Bartkus wrote: "Magnus Lycka" <ly***@carmen.se> wrote in message > The O.P. wanted a database for his > Python app, and Thomas Bartkus suggested Access. Not exactly!
Sorty, I meant Jet or whatever the backend is called these days.
I suggested the built in Microsoft DAO or ADO database libraries which he could use without need to distribute with his app. The Access application is simply another client app that sits on top of DAO/ADO and would be quite unnecessary here. Any Python/DB application you wished to distribute for MS Windows would do best talk to the ADO library directly - end of distribution problems.
If we start with vanilla Python, we need just the tiny PySqlite module
and DB-API compliant Python code to get a SQLite solution to work. One
small 3rd party module which is trivial to bundle. There is no way you
can access ADO with less 3rd party stuff bundled than that. The minimum
is to bundle win32all or ctypes, but then you need to work much harder.
You probably want a 3rd party python ADO library as well. Then it's
much more stuff to bundle.
"Magnus Lycka" <ly***@carmen.se> wrote in message
news:d9**********@wake.carmen.se... Thomas Bartkus wrote: "Magnus Lycka" <ly***@carmen.se> wrote in message > The O.P. wanted a database for his > Python app, and Thomas Bartkus suggested Access. Not exactly!
Sorty, I meant Jet or whatever the backend is called these days.
Hey! Even MS is confused these days. If we start with vanilla Python, we need just the tiny PySqlite module and DB-API compliant Python code to get a SQLite solution to work. One small 3rd party module which is trivial to bundle. There is no way you can access ADO with less 3rd party stuff bundled than that. The minimum is to bundle win32all or ctypes, but then you need to work much harder. You probably want a 3rd party python ADO library as well. Then it's much more stuff to bundle.
I was thinking of Win32com which I expect lets you put a wrapper around ADO
and work the ADO (or any other ActiveX) object model from within Python.
However
I must confess that while I am quite familiar with ADO, I haven't used it
with Python.
I do know that the ADO (or DAO) libraries are complete, SQL oriented,
database systems that are available on every WinXP desktop. I *think* "Jet"
refers to the underlying, .mdb file based storage engine that ADO rides on
top of by default. All WinXP platforms have this and do not need another db
platform - IOW we don't need to distribute a db platform here!
Unless one simply prefers something else ;-)
Thomas Bartkus
On 6/22/2005 3:08 PM, Cameron Laird wrote: In article <3t***************@news.uswest.net>, Dan <da*@nospam.com> wrote:
On 6/22/2005 1:14 PM, Dave Cook wrote:
On 2005-06-22, Cameron Laird <cl****@lairds.us> wrote: Are you saying that Python-based applications are particularly vulnerable in this all-too-common scenario? If so, I'm not getting it; why is the architecture described more fragile than more traditional Windows-oriented development patterns? If not, then, ... well then I truly don't get your point.
Maybe the point is the downside of depending on installed DLLs rather than shipping your own.
Dave Cook
Yes, DLL hell.
?
OK, I'm with you part of the way. Typical "Access" developers are *always* involved with DLL hell, right? You're surely not saying that Python worsens that frustration, are you?
No.
On 6/22/2005 9:51 PM, Peter Hansen wrote: Will McGugan wrote:
Thanks for the replies. I think I'm going to go with sqllite for now.
Your list didn't mention a few things that might be critical. Referential integrity? Type checking? SQLite currently supports neither. Just make sure you check the list of supported features to see that it really does what you need.
-Peter
So in SQLLite, what happens of you try to store XYZ in an integer field?
Dan wrote: So in SQLLite, what happens of you try to store XYZ in an integer field?
Without your having enabled any of the "affinity" options mentioned by
Dave Cook, SQLite will happily store 'XYZ' in that column, and return it
to you when you query that row. The types are either ignored, or
advisory, or meaningful in various ways, depending on the settings you pick.
Note that this is considered something as a desirable feature in the
SQLite community, in a similar fashion (it appears to me) to how dynamic
typing is considered in the Python community, so don't consider it
outright to be a Bad Thing. I'd say more on the issue, if I knew
anything that I hadn't just read in the documentation. ;-)
-Peter
Thomas Bartkus wrote: I was thinking of Win32com which I expect lets you put a wrapper around ADO and work the ADO (or any other ActiveX) object model from within Python.
Sure, but since others have made wrappers around ADO for Python before,
you'd either reivent the wheel or or use e.g. http://www.ecp.cc/pyado.html or http://adodbapi.sourceforge.net/
and get another dependency besides the Win 32 libs.
Your milage may vary, but I prefer to use the DB-API compliant
interfaces. If mxODBC is ok from a licence point of view, I'm sure
it's an excellent product, but if you use it for .mdb I suspect you
need to deal with Jet oddities like quoting dates with # and
non-standard wildcard symbols. (* and ? instead of % and _). That
was the case last time I tried. :(
Maybe modern Jet versions have done away with those absurdities, but
then I guess you are in trouble if you install the program on a machine
with somwhat older Windows software.
If the limited SQL support in SQLite is enough, I think it's a very
simple and straight forward tool to use in Windows from Python.
Try it! This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Neuruss |
last post by:
IronPython is currently at a pre-alpha stage suitable for
experimentation but not for serious development work.
http://www.ironpython.com
|
by: cooldv |
last post by:
i am running a website on Windows 2000 server with ASP 3 webpages and
Access 2000 database. (with a hosting company)
traffic is slow at this time but expect to grow. lately i have been
reading...
|
by: Saravanakumar |
last post by:
Recently I have changed the VB Application for Authentication method
to connect to the SQL Server 7.0 database using the Windows NT
Authentication.
Later I had created permissions for Select,...
|
by: allenj |
last post by:
DB2 UDB 7.2 WSE
Fixpak 9
Linux Red Hat 7.3
I am in the midst of making some changes to a Sybase
Powerbuilder-based Windows graphical user interface that
uses DB2.
Some requests/complaints I...
|
by: Rod Early |
last post by:
I have the task of converting a SQL Server 2000 database to
PostgreSQL. The data itself does not need to be converted, but the
structure and stored procedures must be.
I expect that converting...
|
by: DeepDiver |
last post by:
I am developing an inventory database in SQL Server. I realize there are
many commercial (as well as some non-commercial) inventory offerings, but my
client has specific requirements that would...
|
by: Allison |
last post by:
Hi -- we are a small manufacturing looking for a multi-user database to
take customer orders (nothing too complicated, with 3 users total). We
think we should be using Access, but are wondering...
|
by: EP |
last post by:
I need to build a fairly simple application that will reside on remote
storage, not on a server, and I am looking for any best practices and
approaches that have worked for others. I believe...
|
by: Carl |
last post by:
I'm a relative newbie to DB2.
I need to move a database from a windows server to a linux server. I
have already identified and resolved an issue with schema names, but I
now have a vexing...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM).
In this month's session, the creator of the excellent VBE...
|
by: MeoLessi9 |
last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
|
by: DolphinDB |
last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation.
Take...
|
by: Aftab Ahmad |
last post by:
Hello Experts!
I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
|
by: Aftab Ahmad |
last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below.
Dim IE As Object
Set IE =...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: ArrayDB |
last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
| |