Member Avatar for abelingaw

I'm having trouble connecting to a database file on another PC. In this case, my PC is the client.

Using:

  1. Windows 7 32-bit on both PC's.
  • Same Workgroup
  • Connection verified using cmd (PING)
  • Connected using hub (straight through)
  • Workgroup status: Joined
  1. MS Access 2007 as database app.

My connection string:

    Con.Open "Provider=Microsoft.ACE.OLEDB.12.0;
    Data Source=\\192.168.1.1\SERVERPC\C:\MYDB.accdb;
    Persist Security Info=False;User Id=Admin;
    Jet OLEDB:Database Password = mypassword"

The IP address and database locations are correct.

I'm recieveing error.

Is my connection string wrong or is it on the hardware?

  • 3 Contributors
  • 2 Replies
  • 221 Views
  • 6 Days Discussion Span
  • Latest Post Latest Post by jhai_salvador

Dani AI

Generated

As and suggested, the error almost always comes from an invalid network path rather than a hardware fault: the OLEDB Data Source must point to a network share (server + share name + optional subfolders + file), not to the server's local-drive syntax inserted after the machine name. (learn.microsoft.com)

Checklist to diagnose the network/share side:

  • Confirm the folder that contains the .accdb is explicitly shared (use an explicit share name, not only administrative shares) and that both the share-level and NTFS permissions allow the client to read/write/create files. Access creates a lock file when opened; lack of folder Create/Delete rights is a common cause of connection failures. (learn.microsoft.com)
  • From the client, browse to the server by entering the server name or IP in Explorer (the UNC volume) and try creating/deleting a simple text file to prove both access and create/delete rights.
  • If browsing fails, check the server firewall and ensure File and Printer Sharing / SMB inbound rules (ports 445/139, NB-Session) are enabled for the active profile. (learn.microsoft.com)

Avoid relying on admin shares (C$) for app access: remote UAC and built‑in restrictions will often block access unless correct credentials and policies are used. Create a proper share with explicit permissions for the account that the client will use. (learn.microsoft.com)

Finally, confirm the Access engine on the client side: the ACE OLEDB provider must be installed and its bitness must match the running application (VB6 is 32‑bit, so install the 32‑bit Access Database Engine if necessary). After the share/permissions/provider are fixed, test by opening the ACCDB from the client Explorer or by launching Access against the UNC path; if that works, the connection string will succeed. (microsoft.com)

Summary: fix the share (explicit share + NTFS permissions), confirm SMB/firewall, avoid C$/UAC pitfalls, and ensure the ACE provider (correct bitness) is present — those steps resolve almost all VB6→ACCDB LAN connection errors.

Recommended Answers

All 2 Replies

Member Avatar for Reverend Jim

A share path is usually specified as

\\MACHINE\SHARE\PATH\FILE

where SHARE is defined on the sharing machine and is never specified as an actual device like C:. If an administrative share is used, C: might be replaced with C$. In any case, if you can't browse to the file using the share path then you won't have access to it through the application. So try typing

\\SERVERPC\C$

into the address bar of an explorer window and see if you can browse to the folder containing MYDB.accdb.

Member Avatar for jhai_salvador
  1. If you shared your ms access database, it might look something like this;

\192.168.1.1\SERVERPC\MYDB.accdb

and NOT \192.168.1.1\SERVERPC\C:\MYDB.accdb;

Try to open \192.168.1.1\SERVERPC\ and see if the database exist or not.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.