#Visual studio import ms access database code#

#Visual studio import ms access database code#

I looked around and cobbled together some code so that he can make a copy of the database, convert the linked tables to local tables, and play around to his heart’s content. The message box tells them they need to use the icon to open the database so that the front-end updater can make sure they're working from the latest version of the database.Ī colleague - another programmer - mentioned that he’d like to take a look and play around with the data but because it’s live and we have no development or test environment, he is reluctant to do so. This way, in the unlikely event they open the database directly instead of through the icon, the database can check the version numbers, return a message box if they don't match and close the database. Within the database is a local table with a version number that checks a SQL table with a version number to determine whether the database is the latest (do the version numbers match). This process puts a tool icon on their desktop and saves the database to their hard drive. We issue the MS Access front end to members of our team through an automated front-end updater. So, I'll come back to writing the code later. Also, my experience with SQL Server is progressing but not to the point of being able to quickly write the code in the time needed to complete this project. Although eventually I'd like to run all my processes through stored procedures in SQL Server so that the front end platform could be changed, the volume of data is small enough to run my processes through MS Access VBA. I have created a MS Access database front end using SQL Server as the backend for data storage only. Also, I acknowledge that there may be several other alternatives to what I'm presenting but recognize that's usually the case with any challenge we face. Even without the second condition, if you have a development or test environment, I would recommend using those environments instead of what is presented in the article. Without these 2 conditions, I would not present this article as a possible work around.

We have an MS Access front end using tables in SQL Server but we are not using any other components of SQL Server (i.e., we are not utilizing stored procedures, views, table-valued functions, etc.).We have a SQL Server production environment but no development or test environment and.

What I'm presenting in this article is the result of 2 conditions in my work area: