Best way to accomplish this task?
We have an access database, which is being used by multiple police departments. The database is split front-end/back-end. The backend sits on the department's servers. The front-end sits on the client machine with a .txt file that shows the path to the backend. The front-ends are not installed in the same directory on each client.
I am creating a vb.net application which will do some importing into the access database. Since each department has different locations where the front end and back end sit, what would the easiest way to get the location of the backend so I can connect to it through the vb.net and accomplish what I need to do?
Do I do a search for the .txt file that shows the location of the back-end? I believe that would take a long time to accomplish. Do I create an application for each department individually? I would rather stay away from that due to update on future code.
I am creating a vb.net application which will do some importing into the access database. Since each department has different locations where the front end and back end sit, what would the easiest way to get the location of the backend so I can connect to it through the vb.net and accomplish what I need to do?
Do I do a search for the .txt file that shows the location of the back-end? I believe that would take a long time to accomplish. Do I create an application for each department individually? I would rather stay away from that due to update on future code.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Here is what I would do:
First round of "update" application searches the drive for the TXT file then stores it in an appropriate location in either HKLM or HKCU in the registry - HKLM\Software\PDDatabase\D
Subsequent updaters can see if the registry key exists and, if not, search the drive and write the key. If it finds the key, it verifies the location of the file and tests to ensure it can connect to the backend server with the information from the text file.
I would say that keeping the information in the registry would, in the long term, be a better place than a TXT file or an INI file, but having the location of the text file stored in a known, programmatically-controlla
One thing about the search for the TXT file: Enumerate all instances of said file and validate which copy it might be - a TXT file that is kilobytes in size is likely not it. Is the TXT file going to be in a folder that is in the %PATH% of the user's environment? If so, you could dramatically limit your search scope by only searching for the file along the path.
First round of "update" application searches the drive for the TXT file then stores it in an appropriate location in either HKLM or HKCU in the registry - HKLM\Software\PDDatabase\D
Subsequent updaters can see if the registry key exists and, if not, search the drive and write the key. If it finds the key, it verifies the location of the file and tests to ensure it can connect to the backend server with the information from the text file.
I would say that keeping the information in the registry would, in the long term, be a better place than a TXT file or an INI file, but having the location of the text file stored in a known, programmatically-controlla
One thing about the search for the TXT file: Enumerate all instances of said file and validate which copy it might be - a TXT file that is kilobytes in size is likely not it. Is the TXT file going to be in a folder that is in the %PATH% of the user's environment? If so, you could dramatically limit your search scope by only searching for the file along the path.
I assume that each and every police department uses the same application to first open front-end txt file to get path to back-end access database file, then to open back-end database to work with. If that application used by police departments does have a logic to find the txt file no matter which client machine it is running on, then I think you might be able to use the same logic to find and read front-end txt file.
Another option could be possible if your front-end txt file is installed by an installer, and your front-end txt file path is relative to the installation folder, then you could try to lookup into Windows Installed Programs list and then find the installation folder.
Otherwise, if your front-end txt file is manually copied to client machine. I don't really see any option for you to accomplish and make a generic database updater application. The only option is that your new database updater application should ask for the path to front-end txt file when being executed on client-machine. And if your database updater application is going to be used a lot in the future, you can save the path to front-end txt file right away (to a fixed location or to registry) on the first time it is specified on each client machine and then just load it next time database updater application runs.
Another option could be possible if your front-end txt file is installed by an installer, and your front-end txt file path is relative to the installation folder, then you could try to lookup into Windows Installed Programs list and then find the installation folder.
Otherwise, if your front-end txt file is manually copied to client machine. I don't really see any option for you to accomplish and make a generic database updater application. The only option is that your new database updater application should ask for the path to front-end txt file when being executed on client-machine. And if your database updater application is going to be used a lot in the future, you can save the path to front-end txt file right away (to a fixed location or to registry) on the first time it is specified on each client machine and then just load it next time database updater application runs.
Hi.
In my opinion, you can locate all backend files on one serverand in the same folder (if possible), then you can access all backend files easily with your .net app.
To access the backend files from Access you can use the UNC path instead of using mapped drives. A UNC path is the form \\ServerName\ResourceName\
You can obtain the UNC path from the Mapped_Drive:\Folder by using the Scripting.FileSystemObject
If you need help for using the FileSystemObject, please, feel free to ask.
Best regards.
Antonio.
In my opinion, you can locate all backend files on one serverand in the same folder (if possible), then you can access all backend files easily with your .net app.
To access the backend files from Access you can use the UNC path instead of using mapped drives. A UNC path is the form \\ServerName\ResourceName\
You can obtain the UNC path from the Mapped_Drive:\Folder by using the Scripting.FileSystemObject
If you need help for using the FileSystemObject, please, feel free to ask.
Best regards.
Antonio.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial