We value your feedback.
Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!
Solved
Application crashing accessing DAO odbcdirect under different user than administrator
Posted on 2004-04-30
Hello everybody
Summary:
I have a problem with a VB application using DAO 3.6 or 3.51 that will not run only under administrator account.
Under a normal domain user account a Run-Time Error 3633 occurs when calling the CreateWorkspace method in the application.
Problem description:
My environment is Windows XP, I have DA0 3.6 installed on my system, SQL server 2000, Visual Basic 6.0
I have a small Visual Basic application that accesses both an SQL database and a Foxpro table.
Both are accessed using DAO 3.6 and their coresponding ODBC drivers.
I create 2 workspaces for each connection:
1) For the connection to the SQL database:
sConnectionString = "ODBC;DATABASE=MyDatabaseN
Set wrkSql = CreateWorkspace("SqlWorksp
2) For the connection to the Foxpro table:
sConnectionString = "ODBC;DRIVER={Microsoft FoxPro VFP Driver (*.dbf)};" & _
"UID=;Deleted=Yes;Null=Yes
"Exclusive=No;SourceType=D
"SourceDB=" + DataPathToThePhysicalFile + ";"
Set wrkEdi = CreateWorkspace("FoxproWor
The program run with no glitch on my developing system (Windows XP).
At the client's site - Windows 2000 Server used as a Terminal Server were all the users log in and do their work it also runs with no glitch under the administrator account.
If I log in as a normal domain user the program will through:
1) If a try to open first the Foxpro workspace - a Run Time Error 3633 with the message - Can't load DLL "?????L?"
2) If a try to open first the SQL workspace - a Run Time Error 3633 with the message - Can't load DLL "MSRDO20.DLL
There is a MSDN support article on this problem:
http://support.microsoft.com/default.aspx?scid=kb;en-us;260369
but it does not answert the question on why the program runs ok with administrator account and doesn't run ok with a normal account.
I have checked and the normal user seems to have access to all the required dlls for thsi project.
Please advise how could I solve this issue.
Thank you
Summary:
I have a problem with a VB application using DAO 3.6 or 3.51 that will not run only under administrator account.
Under a normal domain user account a Run-Time Error 3633 occurs when calling the CreateWorkspace method in the application.
Problem description:
My environment is Windows XP, I have DA0 3.6 installed on my system, SQL server 2000, Visual Basic 6.0
I have a small Visual Basic application that accesses both an SQL database and a Foxpro table.
Both are accessed using DAO 3.6 and their coresponding ODBC drivers.
I create 2 workspaces for each connection:
1) For the connection to the SQL database:
sConnectionString = "ODBC;DATABASE=MyDatabaseN
Set wrkSql = CreateWorkspace("SqlWorksp
2) For the connection to the Foxpro table:
sConnectionString = "ODBC;DRIVER={Microsoft FoxPro VFP Driver (*.dbf)};" & _
"UID=;Deleted=Yes;Null=Yes
"Exclusive=No;SourceType=D
"SourceDB=" + DataPathToThePhysicalFile + ";"
Set wrkEdi = CreateWorkspace("FoxproWor
The program run with no glitch on my developing system (Windows XP).
At the client's site - Windows 2000 Server used as a Terminal Server were all the users log in and do their work it also runs with no glitch under the administrator account.
If I log in as a normal domain user the program will through:
1) If a try to open first the Foxpro workspace - a Run Time Error 3633 with the message - Can't load DLL "?????L?"
2) If a try to open first the SQL workspace - a Run Time Error 3633 with the message - Can't load DLL "MSRDO20.DLL
There is a MSDN support article on this problem:
http://support.microsoft.com/default.aspx?scid=kb;en-us;260369
but it does not answert the question on why the program runs ok with administrator account and doesn't run ok with a normal account.
I have checked and the normal user seems to have access to all the required dlls for thsi project.
Please advise how could I solve this issue.
Thank you
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
3-
3
8 Comments
Indeed I should have started using ADO when I developed the aplication.
I am not sure of the overhead of changing from DAO to ADO but because I am under presure from management to finish off the project it might to late for a conversion now.
Anyway I found the solution and I just wanted to posted for future reference:
Registering MSRDO20.DLL under that specific domain user solved the problem (the DLL was located in the system32 directory but not seen as registered by that specific domain user).
c:\winnt\system32\regsvr32
But of course I may need to do this for all the users that connect remotely to that Terminal Server.
Again the question comes up of why under administrator account the MSRDO20.DLL can be loaded by the application while under other accounts this fails.
The possible answer lies in the fact that to install correctly something on a Terminal Server you must put the system into Install Mode.
I believe that MS Office was install under administrator account without putting the system into INSTALL MODE and that has resulted in the other users not having some of the DLL's registered.
Of course this is only a theory since the tests needed to confim / unconfirm this need resources that I don't have at this point.
Thank you for the tip about using ADO for future projects as it seems to pay off due to less problems than with using DAO.
Regards
I am not sure of the overhead of changing from DAO to ADO but because I am under presure from management to finish off the project it might to late for a conversion now.
Anyway I found the solution and I just wanted to posted for future reference:
Registering MSRDO20.DLL under that specific domain user solved the problem (the DLL was located in the system32 directory but not seen as registered by that specific domain user).
c:\winnt\system32\regsvr32
But of course I may need to do this for all the users that connect remotely to that Terminal Server.
Again the question comes up of why under administrator account the MSRDO20.DLL can be loaded by the application while under other accounts this fails.
The possible answer lies in the fact that to install correctly something on a Terminal Server you must put the system into Install Mode.
I believe that MS Office was install under administrator account without putting the system into INSTALL MODE and that has resulted in the other users not having some of the DLL's registered.
Of course this is only a theory since the tests needed to confim / unconfirm this need resources that I don't have at this point.
Thank you for the tip about using ADO for future projects as it seems to pay off due to less problems than with using DAO.
Regards
I have posted request for closing and refund in the Community Support for this question 8 days ago allready and still nothing happend.
How do I close the question ?
How do I close the question ?
Featured Post
Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.
One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
The debugging module of the VB 6 IDE can be accessed by way of the Debug menu item. That menu item can normally be found in the IDE's main menu line as shown in this picture.
There is also a companion Debug Toolbar that looks like the followin…
Background
What I'm presenting in this article is the result of 2 conditions in my work area:
We have a SQL Server production environment but no development or test environment; andWe have an MS Access front end using tables in SQL Server but we a…
Get people started with the process of using Access VBA to control Outlook using automation, Microsoft Access can control other applications. An example is the ability to programmatically talk to Microsoft Outlook. Using automation, an Access applic…
Show developers how to use a criteria form to limit the data that appears on an Access report. It is a common requirement that users can specify the criteria for a report at runtime. The easiest way to accomplish this is using a criteria form that a…
Suggested Courses
Course of the Month10 days, 16 hours left to enroll
719 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.