problems with DSN for MS Acess database

[kdv09]

Hi!
I'm looking for some help in fixing my screwup:

I've got C++ app which reads MDB database, using MFC CDatabase and
CRecordset derived classes. I had it working OK on development PC (Win
XP SP2) with MS Access 2000 installed (the app itself does not use MS
Access). I moved the app on another PC (also Win XP SP2) without MS
Access. After some poking around I've figured out that the app does not
work because DSN it is using was not available. So I created System DSN
for MS Access Database by hand and my app was working OK.

After that by silly mistake User DSN for MS Access Database was created
on the development PC (the one with existing and working MS Access).
This upset performance of database access very badly - it takes very
long time to read and move through the records.
I've (1) unrolled XP to earlier date, (2) reinstalled MS Access - still
have the problem.

MS Access itself seems to be OK, no noticeable degradation of speed,
but CDatabase.Open and ExecuteSQL, CRecordset::MoveFirst MoveNext, etc
take very long time. It also looks like increased disk activity during
those operations.

So, any hints on what's going on and how stop it from going on like
that?

Many thanks
kdv09

[Sky]

<kd***@excite.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
....

After that by silly mistake User DSN for MS Access Database was created
on the development PC (the one with existing and working MS Access).
This upset performance of database access very badly - it takes very
long time to read and move through the records

You could check the Advanced parameters in the ODBC setup.

Or you could extract the registry entries and compare them between the two
computers. To do this, open RegEdit and look at the keys for:

[HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI\YourOdbcD sN]

if it is a User DSN,

or

[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\YourOdbc DsN]

if it is a System DSN.

You can use RegEdit File Export to save text files for these keys and
compare the results.

If you have both User and System DSN, the User DSN wins, when you connect in
C++ using ODBC.

One parameter to check is buffer size, located at:

[HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI\YourOdbcD sN\Engines\Jet]
"MaxBufferSize"=dword:00008000 ; or whatever size you want

- Steve

[Steve Jorgensen]

On 19 Dec 2005 21:02:12 -0800, kd***@excite.com wrote:

Hi!
I'm looking for some help in fixing my screwup:

I've got C++ app which reads MDB database, using MFC CDatabase and
CRecordset derived classes. I had it working OK on development PC (Win
XP SP2) with MS Access 2000 installed (the app itself does not use MS
Access). I moved the app on another PC (also Win XP SP2) without MS
Access. After some poking around I've figured out that the app does not
work because DSN it is using was not available. So I created System DSN
for MS Access Database by hand and my app was working OK.

After that by silly mistake User DSN for MS Access Database was created
on the development PC (the one with existing and working MS Access).
This upset performance of database access very badly - it takes very
long time to read and move through the records.
I've (1) unrolled XP to earlier date, (2) reinstalled MS Access - still
have the problem.

MS Access itself seems to be OK, no noticeable degradation of speed,
but CDatabase.Open and ExecuteSQL, CRecordset::MoveFirst MoveNext, etc
take very long time. It also looks like increased disk activity during
those operations.

So, any hints on what's going on and how stop it from going on like
that?

Many thanks
kdv09

Did you accidentally turn SQL logging on for the DSN?

[kdv09]

Sheesh, this could be it! As a matter of fact I do have it on at the
moment - trying to figure out what's wrong. I'll check this first thing
tomorrow when I get back to the PC in question!
Logging would slow down all DB operations for sure, so this is a very
good guess!!!
Many thanks
kdv09
Steve Jorgensen wrote:

On 19 Dec 2005 21:02:12 -0800, kd***@excite.com wrote:

Hi!
I'm looking for some help in fixing my screwup:

I've got C++ app which reads MDB database, using MFC CDatabase and
CRecordset derived classes. I had it working OK on development PC (Win
XP SP2) with MS Access 2000 installed (the app itself does not use MS
Access). I moved the app on another PC (also Win XP SP2) without MS
Access. After some poking around I've figured out that the app does not
work because DSN it is using was not available. So I created System DSN
for MS Access Database by hand and my app was working OK.

After that by silly mistake User DSN for MS Access Database was created
on the development PC (the one with existing and working MS Access).
This upset performance of database access very badly - it takes very
long time to read and move through the records.
I've (1) unrolled XP to earlier date, (2) reinstalled MS Access - still
have the problem.

MS Access itself seems to be OK, no noticeable degradation of speed,
but CDatabase.Open and ExecuteSQL, CRecordset::MoveFirst MoveNext, etc
take very long time. It also looks like increased disk activity during
those operations.

So, any hints on what's going on and how stop it from going on like
that?

Many thanks
kdv09

Did you accidentally turn SQL logging on for the DSN?

[kdv09]

Thanks, Steve - i'll verify this as soon as I'm back to work tomorrow!
BTW, Is there any way to check and create DSNs programmatically (I had
a cursory look only and could not find anything yet)?
regards
kdv09

[David W. Fenton]

kd***@excite.com wrote in
news:11**********************@g49g2000cwa.googlegr oups.com:

i'll verify this as soon as I'm back to work tomorrow!
BTW, Is there any way to check and create DSNs programmatically (I
had a cursory look only and could not find anything yet)?

Can't you do DSN-less connections? Google the term.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Sky]

<kd***@excite.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Thanks, Steve - i'll verify this as soon as I'm back to work tomorrow!
BTW, Is there any way to check and create DSNs programmatically (I had
a cursory look only and could not find anything yet)?
regards
kdv09

You can directly write the ODBC registry entries using standard Windows API
from C++. Or you can write to the registry in your installer program (I
recommend InnoSetup).

Or, you can use RegEdit File Export to create a .reg file, fix it up the way
you want it in Notepad, and then in your C++ program Shell out to add the
..reg file. The Shell command would be something like:
RegEdit /S MyOdbcSetupl.Reg

- Steve

[kdv09]

Yep, the problem was in activating logging, rather than in DSN itself!
many thanks for your help
kdv09

kd***@excite.com wrote:

Sheesh, this could be it! As a matter of fact I do have it on at the
moment - trying to figure out what's wrong. I'll check this first thing
tomorrow when I get back to the PC in question!
Logging would slow down all DB operations for sure, so this is a very
good guess!!!
Many thanks
kdv09
Steve Jorgensen wrote:

On 19 Dec 2005 21:02:12 -0800, kd***@excite.com wrote:

Hi!
I'm looking for some help in fixing my screwup:

I've got C++ app which reads MDB database, using MFC CDatabase and
CRecordset derived classes. I had it working OK on development PC (Win
XP SP2) with MS Access 2000 installed (the app itself does not use MS
Access). I moved the app on another PC (also Win XP SP2) without MS
Access. After some poking around I've figured out that the app does not
work because DSN it is using was not available. So I created System DSN
for MS Access Database by hand and my app was working OK.

After that by silly mistake User DSN for MS Access Database was created
on the development PC (the one with existing and working MS Access).
This upset performance of database access very badly - it takes very
long time to read and move through the records.
I've (1) unrolled XP to earlier date, (2) reinstalled MS Access - still
have the problem.

MS Access itself seems to be OK, no noticeable degradation of speed,
but CDatabase.Open and ExecuteSQL, CRecordset::MoveFirst MoveNext, etc
take very long time. It also looks like increased disk activity during
those operations.

So, any hints on what's going on and how stop it from going on like
that?

Many thanks
kdv09

Did you accidentally turn SQL logging on for the DSN?

[kdv09]

Cool! I was just thinking there might be some API like CreateDSN or
something. But distributing and importing reg file with installation is
OK
Thank you for your help
kdv09

[kdv09]

David,
thanks for the suggestions! As a matter of fact, I had no particular
preference, just used some code from example i saw somewhere and it
worked. But now, after you've mentioned the issue I can see that using
DSN might be somewhat limiting in my application and DSN-less
connection could be a bettter choice - I will investigate and try to
use DSN less connection
Many thanks
kdv09

[Sky]

<kd***@excite.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

Cool! I was just thinking there might be some API like CreateDSN or
something. But distributing and importing reg file with installation is
OK
Thank you for your help
kdv09

I believe the ODBC library does have functions to create DSNs at run time,
but I have never used them. I find it easer to simply write to the registry.
And if you use a static ODBC connection that does not change, then it is
easier to make the ODBC setup part of your install procedure, not part of
your program itself.

- Steve

[Sky]

<kd***@excite.com> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...

David,
thanks for the suggestions! As a matter of fact, I had no particular
preference, just used some code from example i saw somewhere and it
worked. But now, after you've mentioned the issue I can see that using
DSN might be somewhat limiting in my application and DSN-less
connection could be a bettter choice - I will investigate and try to
use DSN less connection
Many thanks
kdv09

My understanding was that this is an existing C++ program that calls the
standard ODBC library directly, not the ADO interface and not an Access
application with table links.

- Steve

[Bernard Peek]

In message <11**********************@g14g2000cwa.googlegroups .com>,
kd***@excite.com writes

Hi!
I'm looking for some help in fixing my screwup:

I've got C++ app which reads MDB database, using MFC CDatabase and
CRecordset derived classes. I had it working OK on development PC (Win
XP SP2) with MS Access 2000 installed (the app itself does not use MS
Access). I moved the app on another PC (also Win XP SP2) without MS
Access. After some poking around I've figured out that the app does not
work because DSN it is using was not available. So I created System DSN
for MS Access Database by hand and my app was working OK.

I notice you got the problem fixed. Other people working with file DSNs
may like to know that the File DSN is a simple text file that can be
hand-edited if necessary. The only problem is that they appear to use
UNIX style line-end codes, so Notepad and other text editors can't edit
them. But Wordpad can edit UNIX text files and so can be used to edit a
File DSN.

--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author.

[David W. Fenton]

"Sky" <sk*@NOSPAMstanleyassociates.com> wrote in
news:LK0qf.42497$eI5.3953@trnddc05:

<kd***@excite.com> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...

David,
thanks for the suggestions! As a matter of fact, I had no
particular preference, just used some code from example i saw
somewhere and it worked. But now, after you've mentioned the
issue I can see that using DSN might be somewhat limiting in my
application and DSN-less connection could be a bettter choice - I
will investigate and try to use DSN less connection

My understanding was that this is an existing C++ program that
calls the standard ODBC library directly, not the ADO interface
and not an Access application with table links.

I don't know anything about C++, but many programming environments
have db libraries that would allow DSN-less connections. However,
the only ones I know about are much further from the metal than C++.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

kd***@excite.com wrote in
news:11**********************@g44g2000cwa.googlegr oups.com:

But distributing and importing reg file with installation is
OK

Might not work on a machine with the registry permissions locked
down. You could probably avoid that by making sure the registry
entry you write is in the current user hive, and not in local
machine (which would be accessible only to users running with
administrative permissions, or with custom registry permissions that
allow users to write to it).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/