JRO synchronization using VB6 and MS Access Permissions issue

I have created an application in VB6 (XP Operating System) that uses an Access Database backend. The application is to be installed to a laptop where a user can enter data without being logged into out network (MS Active Directory) because each laptopt has a replica database. The master resides on one of our servers. When a user needs to synchronize there data, they log in to our netword, open the application and click a button. The button runs a sub that is using JRO to do the sync.
My problem:
When I run my application (I have admin rights to the entire network), I don't have a problem with the synchronization process. But if I log into the network as a regular user (User Rights), I get a run time error 13 saying Type mis match. I know the problem is the permissions of the user loging into the network, but I'm not sure about how to go and fix the problem.
I thought if I got feed back from others they might be able to direct me to a better way of doing what I am doing, or maybe state something that might resolve the permissions issue.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Not sure about JRO, I use ADO.  What statement are you getting the 13 on?
AmericaFanAuthor Commented:
quiklearner, Sorry. I'm new here. I figured out what the problem was. Users need to have Power User Rights on their laptops in order for the database to sync.
Is ADO better? I only used the JRO because I found an example years ago and never thought to look and find how to do it other ways.
Well from what I know, ADO (ActiveX Data Objects) is pretty easy to use.  It offers easy support for connecting to most db types, and has ties into the datasource properties of the standard listboxes/comboboxes.  Releases of it are included in Microsofts MDAC installs/updates (Microsoft Data Access Components).  If you are familiar with the object browser (f2 in the VB IDE) you could reference anything labeled "Microsoft ActiveX Data Objects X.X Library" where X.X is the version; you probably several but choose just one, and look through it.  Your built-in help (f1) will contain help on the objects/methods/properties too.
Now I am curious as to what would have generated a type mismatch based on that.  Did you ever isolate the line it was occuring on?  To do so just run it in debug.  If you can't, guess as to where the issue occurs.  Number the lines and assuming you are not trapping for errors add "On Error Goto PROC_ERROR" to the top of the function/sub/property.  Remember, if you call other functions/subs/properties of yours, you will need to also modify those functions/subs/properties to do this as well.  At the end of each of these functions/subs/properties place:

Exit Function/Sub/Property
MsgBox "Runtime Error " &  Err.Number & "(Function/Sub/Property Name:" & VBA.Erl & ")" & vbCrLf & _  
End Function/Sub/Property

Then compile it.  This will tell you where the problem is.  Line numbers go on every line except Public/Private/Friend/Dim statements as well before the first Case, after the select statement.  Usually people initially numbers lines in multiples of ten so there is room to grow without having to renumber a bunch (you still me have to some):

10  If x = 45 Then
20      MsgBox "I got " & x
30  End If

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
AmericaFanAuthor Commented:
I never knew I supposed to place the error routeen in fuctions/sub within fuctions/sub. Maybe that is why don't always work :)
If you want to isolate it all the way down to the actual line it errors on, it would be a good idea.  If you are not concerned about that much granularity then you probably don't need to.  BTW I forgot to point out that in the sample above VBA.Erl prints the line number the error occured on..
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.