Tavirgil
asked on
Application crashing accessing DAO odbcdirect under different user than administrator
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
ASKER
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
Sorry could not have been of more help. Good luck. BTW you should ask for a refund.
Leon
Leon
ASKER
Thanks for that and ADO tip.
Virgil
Virgil
No problem and please close this question.
Leon
Leon
ASKER
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 ?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Leon