Records created on one PC are not visible on the other

Greetings, everybody!

I have developed an application in VB.NET that works with MS Access database. I installed this software on one PC (Windows 7), which is considered as the server, since it is hosting the database sharing it on the local network. The empty database file is installed together with the other files of my deployment project package, which is a part of my VB.NET solution. The software works fine on this machine.

Then, I installed the software on a different workstation (Windows XP). The connection to the db is established without troubles, except for the unpleasant detail that no records created by the server's application are visible.

Besides, when I open the database file and check any table, no entry appear either (neither openning the file on the workstation, nor on the server itself). The structure of the tables is OK, though.

In other words, the data registered by the server's software can only be viewed through the server's software. And the data inserted by the other workstation or openning the db file directly can be viewed anywhere, except through the server's software.

I have revised the Windows 7 permissions for the db folder and file to accept remote connections. So did I for the db MS Access properties. The ConnectionString I use for the software to work with the db had always worked fine in other client-server applications with MS Access.

I suspect there's a sort of a data protection mechanism that comes either with Windows 7 or with MS Access 2007. Or I should definitely deploy the db file separately from the other software dependecy files (thing I have not tried yet).

Any advices on this case will be appreciated a lot, because my patience is beginning to run out.


  • Hello, guys.

    Here I am back to post a solution I came up with...

    I did double-check my ConnectionStrings on each machine, but "unfortunately" everything was OK (pointing to the same shared DB on the server).

    Therefore, for those who may have a similar case, here is what I did to work it out:

    - As I had told previously, the data registered via server's application could be visible through the server's application only. Not even openning the DB file with MS Access to view it directly on the same machine. Even the size of the DB file remained the same as it was when I just installed the software.

    - The application is designed to show the OpenFile dialog to select a DB. When it runs for the first time or when the referenced DB is not found. I discovered that the size of the DB file did appear to be greater viewing it through this dialog window.

    - Besides, the Windows 7 on the server is the spanish version. So, the physical directory (in the Windows Explorer) where the software was installed appeared as [b]C:Archivos de programaApplication[/b]. However, checking the ConnectionString of the server's application, the referenced path turned out to be [b]C:Program filesApplication[/b]. Then, I got even more confused, because somehow the connection did get established.

    - So, I decided to avoid messing up with [b]C:Program files [/b]directory. Placed an empty DB in a different partition and folder ([b]D:DB[/b]) which works perfectly with any machine.

    - After that, I copied all the existing data from the troublesome DB to the empty one. To do that, I temporarily added several queries in the source code of my software, since it was the only mean by which the info could be viewed. That's because all the existing data has been registered by the server's application so far. Having the connection object point to the troublesome DB, I used the following sort of quiery for each table:

    INSERT INTO [MS Access;DATABASE=DDBDB.mdb;PWD=password].[TableName]
    SELECT * FROM TableName

    - Finally, I shared the new DB on the network, redirect each machine's application to the new DB.

    I really never found out what the core of my issue was: [b]C:Program files[/b] directory Windows 7 protection mechanism, deploying the DB file as a part of Visual Studio installation package or the path name differences I described above for a different Windows language version in a ConnectionString.

    I just found a work around and really hope these notes will help other guys who might get into similar misleading and ugly situation.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


In this Discussion