Solved

Application crashing accessing DAO odbcdirect under different user than administrator

Posted on 2004-04-30
8
649 Views
Last Modified: 2013-12-25
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=MyDatabaseName;"

  Set wrkSql = CreateWorkspace("SqlWorkspaceName", SqlUserName, SqlPassword, dbUseODBC)

2) For the connection to the Foxpro table:
   sConnectionString = "ODBC;DRIVER={Microsoft FoxPro VFP Driver (*.dbf)};" & _
       "UID=;Deleted=Yes;Null=Yes;Collate=Machine;BackgroundFetch=Yes;" & _
       "Exclusive=No;SourceType=DBF;DNS=;DATABASE=LocalDatabaseName;" & _
       "SourceDB=" + DataPathToThePhysicalFile + ";"

  Set wrkEdi = CreateWorkspace("FoxproWorkspaceName", "admin", "", dbUseODBC)

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
0
Comment
Question by:Tavirgil
  • 3
  • 3
8 Comments
 
LVL 29

Expert Comment

by:leonstryker
ID: 10960684
Try using ADO in a sample application. You may avoid the entire problem all together.

Leon

0
 

Author Comment

by:Tavirgil
ID: 10970488
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 MSRDO20.DLL

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
 
0
 
LVL 29

Expert Comment

by:leonstryker
ID: 10972346
Sorry could not have been of more help.  Good luck.  BTW you should ask for a refund.

Leon
0
Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

 

Author Comment

by:Tavirgil
ID: 10974035
Thanks for that and ADO tip.

Virgil
0
 
LVL 29

Expert Comment

by:leonstryker
ID: 10974041
No problem and please close this question.

Leon
0
 

Author Comment

by:Tavirgil
ID: 11030574
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 ?
0
 
LVL 5

Accepted Solution

by:
Netminder earned 0 total points
ID: 11037213
User resolved; closed, 500 points refunded.

Netminder
Site Admin
0

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
Adding to a VBA? 6 61
message box in access 4 41
MS Date Picker 64 bit 32 bit issue 12 49
Spell Check in VB6 13 98
I’ve seen a number of people looking for examples of how to access web services from VB6.  I’ve been using a test harness I built in VB6 (using many resources I found online) that I use for small projects to work out how to communicate with web serv…
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 Excel using automation, Microsoft Access can control other applications. An example is the ability to programmatically talk to Excel. Using automation, an Access application can laun…
This lesson covers basic error handling code in Microsoft Excel using VBA. This is the first lesson in a 3-part series that uses code to loop through an Excel spreadsheet in VBA and then fix errors, taking advantage of error handling code. This l…

920 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now