By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,818 Members | 1,223 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,818 IT Pros & Developers. It's quick & easy.

Database recommendations for Windows app

P: n/a
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")
Jul 19 '05 #1
Share this Question
Share on Google+
33 Replies


P: n/a
"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
Jul 19 '05 #2

P: n/a
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

Jul 19 '05 #3

P: n/a
Dan
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

Jul 19 '05 #4

P: n/a
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
Jul 19 '05 #5

P: n/a
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.
Jul 19 '05 #6

P: n/a
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.
Jul 19 '05 #7

P: n/a
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

Jul 19 '05 #8

P: n/a
Dan
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.
Jul 19 '05 #9

P: n/a
"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

Jul 19 '05 #10

P: n/a
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.
Jul 19 '05 #11

P: n/a
In article <UJ***************@news.uswest.net>, Dan <da*@nospam.com> wrote:
Jul 19 '05 #12

P: n/a
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
Jul 19 '05 #13

P: n/a
Dan
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.
Jul 19 '05 #14

P: n/a
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
Jul 19 '05 #15

P: n/a
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?
Jul 19 '05 #16

P: n/a
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")
Jul 19 '05 #17

P: n/a
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
Jul 19 '05 #18

P: n/a
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/> <

Jul 19 '05 #19

P: n/a
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/> <

Jul 19 '05 #20

P: n/a
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
Jul 19 '05 #21

P: n/a
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
Jul 19 '05 #22

P: n/a
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.
Jul 19 '05 #23

P: n/a
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
Jul 19 '05 #24

P: n/a
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
Jul 19 '05 #25

P: n/a

"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


Jul 19 '05 #26

P: n/a
In article <sl*********************@localhost.localdomain>,
Dave Cook <da******@nowhere.net> wrote:
On 2005-06-23, Peter Hansen <pe***@engcorp.com> wrote:

Jul 19 '05 #27

P: n/a
"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

Jul 19 '05 #28

P: n/a
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.
Jul 19 '05 #29

P: n/a

"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


Jul 19 '05 #30

P: n/a
Dan
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.
Jul 19 '05 #31

P: n/a
Dan
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?
Jul 19 '05 #32

P: n/a
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
Jul 19 '05 #33

P: n/a
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!
Jul 19 '05 #34

This discussion thread is closed

Replies have been disabled for this discussion.