DSN for MS Acess数据库的问题 [英] problems with DSN for MS Acess database

查看:53
本文介绍了DSN for MS Acess数据库的问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

嗨!

我正在寻找一些帮助来解决我的问题:


我有C ++应用程序读取MDB数据库,使用MFC CDatabase和

CRecordset派生类。我在安装了MS Access 2000的开发PC(Win

XP SP2)上工作正常(应用程序本身不使用MS

Access)。我在没有MS的另一台PC(也是Win XP SP2)上移动了应用程序

Access。经过一番探讨后,我发现应用程序没有工作,因为它使用的DSN不可用。所以我手动为MS Access数据库创建了系统DSN

,我的应用程序工作正常。


之后由于愚蠢的错误用户DSN for MS Access Database在开发PC上创建了

(具有现有和正在使用的MS Access的那个)。

这种不正常的数据库访问性能非常糟糕 - 它需要非常多的

很长时间阅读和浏览记录。

我已经(1)将XP展开到更早的日期,(2)重新安装MS Access - 仍然

有问题。


MS Access本身似乎没问题,没有明显的速度下降,

但CDatabase.Open和ExecuteSQL,CRecordset :: MoveFirst MoveNext,等等

需要很长时间。在这些操作中看起来像是增加了磁盘活动。


因此,任何有关正在发生的事情的提示以及如何阻止它继续下去

那个?


非常感谢

kdv09

解决方案

< kd *** @ excite.com>在留言中写道

news:11 ********************** @ g14g2000cwa.googlegr oups.com ...

....

之后由于愚蠢的错误,在开发PC(具有现有和正在运行的MS Access的PC)上创建了用于MS Access数据库的用户DSN。数据库访问的这种不正常表现非常糟糕 - 需要非常长的时间来阅读和浏览记录




您可以检查高级参数ODBC设置。


或者您可以提取注册表项并在两台

计算机之间进行比较。为此,请打开RegEdit并查看以下键:


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

>
如果是用户DSN,





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


如果是系统DSN。


您可以使用RegEdit文件导出来保存这些密钥的文本文件

比较结果。


如果您同时拥有用户和系统DSN,则当您连接时,用户DSN将获胜

C ++使用ODBC。


要检查的一个参数是缓冲区大小,位于:


[HKEY_CURRENT_USER \ SOFTWARE \ODBC \ _ODBC .INI \YourOdbcD sN\Engines\Jet]

" MaxBufferSize" = dword:00008000;或者你想要的任何尺寸


- 史蒂夫


2005年12月19日21:02:12 -0800, kd *** @ excite.com 写道:

嗨!
我正在寻找为了帮助解决我的问题:

我有一个C ++应用程序,它使用MFC CDatabase和CRecordset派生类来读取MDB数据库。我在安装了MS Access 2000的开发PC(Win
XP SP2)上运行良好(应用程序本身不使用MS
Access)。我在不使用MS
Access的另一台PC(也是Win XP SP2)上移动了应用程序。经过一番探讨后,我发现该应用程序无法正常工作,因为它正在使用的DSN无法使用。所以我手动为MS Access数据库创建了系统DSN,我的应用程序运行正常。

之后由于愚蠢的错误,用户DSN for MS Access数据库在开发时创建了
PC(具有现有和工作MS Access的那个)。
这种令人不快的数据库访问性能非常糟糕 - 阅读和浏览记录需要很长时间。
我已经(1)展开XP到更早的日期,(2)重新安装MS Access - 仍然有问题。

MS Access本身似乎没问题,没有明显的速度降低,但CDatabase.Open和ExecuteSQL,CRecordset :: MoveFirst MoveNext等等需要很长时间。在这些操作过程中,它看起来似乎也增加了磁盘活动。

所以,任何有关正在发生的事情的提示以及如何阻止它继续进行这样做? kdv09




您是否意外地为DSN开启了SQL登录?


Sheesh,这可能是它!事实上,我确实在

时刻 - 试图弄清楚什么是错的。当我回到有问题的PC时,我会检查第一件事



记录会减慢所有数据库操作的速度,所以这是一个非常好的

很好猜!!!

非常感谢

kdv09

Steve Jorgensen写道:

2005年12月19日21:02:12 -0800, kd***@excite.com 写道:

嗨!
我正在寻找一些帮助来解决我的问题:

我有一个C ++应用程序读取MDB数据库,使用MFC CDatabase和CRecordset派生类。我在安装了MS Access 2000的开发PC(Win
XP SP2)上运行良好(应用程序本身不使用MS
Access)。我在不使用MS
Access的另一台PC(也是Win XP SP2)上移动了应用程序。经过一番探讨后,我发现该应用程序无法正常工作,因为它正在使用的DSN无法使用。所以我手动为MS Access数据库创建了系统DSN,我的应用程序运行正常。

之后由于愚蠢的错误,用户DSN for MS Access数据库在开发时创建了
PC(具有现有和工作MS Access的那个)。
这种令人不快的数据库访问性能非常糟糕 - 阅读和浏览记录需要很长时间。
我已经(1)展开XP到更早的日期,(2)重新安装MS Access - 仍然有问题。

MS Access本身似乎没问题,没有明显的速度降低,但CDatabase.Open和ExecuteSQL,CRecordset :: MoveFirst MoveNext等等需要很长时间。在这些操作过程中,它看起来似乎也增加了磁盘活动。

所以,任何有关正在发生的事情的提示以及如何阻止它继续进行这样做? kdv09



你是不是意外地为DSN开启了SQL登录?




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

解决方案

<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


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?


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?




这篇关于DSN for MS Acess数据库的问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆