I've been tasked to take an Access 2007 application that relies on an ODBC connection and share it with other institutions with the same ODBC connection. Please forgive me if I don't communicate this very well. I'm not a developer, but have been tasked with this project since I've gotten it this far. I'm sure that's never happened before...
First I'll give a layout of our structure:
I work for a college that shares an database via ODBC with 31 other schools.
The system office that maintains the database for all campuses only allows us to access the read-only data through a VPN of a Common Access Point server (CAP) that then connects via ODBC
The CAP server (the only location that can link to the ODBC) has Microsoft Office and does not have internet access.
Each campus has a unique ODBC connection that requires relinking tables when the accdb is placed on their CAP server.
With each launch of Access, the user must also login to the ODBC connection.
The CAP server can can read-write on a network drive, but not vice-versa.
We can safely assume that no other software can be installed on the CAP server, but files may be placed (which is why we can distribute an accdb file)
The Access application pulls student course activity from the ODBC and and applies logic to determine if/when the student stops attending all courses. At this time, this logic is a series of queries tied to a macro. The database then generates a report (with more information from the ODBC) of the students. An active tracking process is in place so a record can be cleared from the report unless a change occurs, which will then cause the record to reappear with the changes. This requires data to be stored locally as well since the ODBC is read-only. There are various forms and reports backed by VBA as well.
The goal is to package the software and distribute for launch at all other campuses. So far we've done small distribution by simply sending them the accdb file and having a button that launches the linked table manager. After initial distribution, I will continue developing the software and distributing updates, having to preserve the data locally stored in the accdb.
The catch is that I only have experience with Access and enough knowledge of VBA to be able to google solutions individually as they come up.
My question could be simple or complex, I'm not sure. Basically I'd like to know if there is a more appropriate approach other than what I've been doing: send accdb and the user copies and pastes the only table that needs to be carried over.
Clarification
Would it be practical to convert the accdb to an executable with each version that is distributed? Is this even possible when the ODBC requires reconnecting and the ODBC is unique between campuses?
Requiring the end user to copy and paste the table(s) that store local data from one accdb file to another for each upgrade will eventually lead to data loss - someone somewhere will forget this step during an upgrade.
A more reliable approach would be to create a second accdb database. Call it "YourAppName_data.accdb" or something to that effect and either place it in the same directory as the front-end client or in a subdirectory called "Data". Link the tables from the "data" accdb file to the front-end client.
You can add startup code to your front-end client that can attempt to automatically relink these tables by looking for the data accdb file in the known location. If the program can't find it you can then prompt the user to find it for you. Incidentally, you should be able to do something similar for the ODBC tables as well. You can use code similar to what ChrisPadgham wrote in his answer for this step.
What you have done at this point is separate the data for the application (both the read-only data and the data each school needs to be able to maintain on their own) from the application front-end (the forms, queries, logic and reports).
This will make it easier to distribute updates to the front-end client. End users simply need to copy the front-end client to the correct directory, overwrite the existing file in the directory and run the program.
This will work, but it is still not as robust as it could be since anyone who has access to the CAP server could potentially delete the data files off of the server. (Hopefully each school takes regular backups of this machine to safeguard against data loss.)
As HansUp suggested, you might eventually be better served by moving the data stored in the Access accdb files to a SQL Server database at each location, which will offer a bit better control of who can access the information and would be a bit better at safeguarding the data since SQL Server database files are "locked" on the machine when the server is running. (This would prevent someone from accidentally deleting a file). The downside to SQL Server is that there is a learning curve and it would need to be installed at each school either on the CAP server or some other machine that the CAP server can access on the network. This might be something to work towards over time once you have better information to go off of.
You can add a relink button that loops through the tables in your database and reconnects them
dim tdf as tabledef
dim db as database
db = currentdb
db.tabledefs.refresh
for each tdf in db.tabledefs
with tdf
if len(.connect)>0 then ' this is a table that has a connect string
if left$(.connect)="ODBC" then ' this is an ODBC connection
.connect = newconnectstring
.refreshlink
end if
end if
end with
next
Related
I have a series of Access 2002 "Front-end/Back-end" applications all related to each other. For example, application A has linked tables with application B and vice versa.
The applications are at a stage where daily compaction and repair is required due to the volume and high level of corruption. Moreover, to be able to make the applications work properly, I must make the changes in a virtual environment with Access 2002. I also need to reinstall "Access runtime 2010 - 32bits" and copy the Access files (.mde) on every workstation (Windows 10) every time I am making a change in the applications.
#Gustav This is a temporary option (6 months to 18 months) because the customer would like to go to a complete solution with SQL database. The studied solution is configurable and already has a SQL database schema.
I have already done the test to transfer forms, tables, queries and modules to Access 365 but I have errors in the VBA code. All business rules are coded in the VBA code. I also did the transfer of the tables to SQL Server 2017 but I'm afraid I will have to change a lot of VBA code because of the disuse of the DAO engine in the Access 365 front-end.
In fact, to be clearer, I wonder about the need to change the front end to Access knowing that it is a temporary solution.
Maybe, I should keep the software under respirator by eliminating data history in large tables. The time the client takes their decision. Find the "sweet spot" that would allow me to erase and continue to maintain it without having to worry about corruptions because I have a hard time seeing a substantial gain in the migration to the Access 365 front-end. What do you think?
I have already proposed to migrate applications and tables in the new version of to Access 2019 and even moving on SQL Server. However, for now, I must put the application on the respirator and continue the daily compaction until a decision is made.
I would like to know if there is a gain to migrate from Access 2002 to the Access 2019 version knowing the total limit of 2 GB Access. What are the major constraints he would have to migrate to a SQL database knowing that the VBA application and code uses the DAO method?
#Albert D. Kallal
I really like your answer. I should come to a decision soon.
However, I have 2 additional questions. Perhaps, could you guide me on the subject.
There are two things that have recently came to haunt the tranquility that reigned over these applications.
1- For a unknown reason, one of the applications that was part of the swarm of Access applications was blocked for some time with these errors 'Runtime 3027: Cannot update: Database or object is read only'. The problem is that some users have ignored this error and continue their tasks which caused a data shift.
I had to go back with backup copy because some tables were not updated.
Looking more closely at the error in the VBA code I noticed that it all came from the DAO Recordset.Edit method containing queries with multiples joins.
I managed to work around this problem by modifying the Edit method with DoCmd.RunSQL and by changing the query from a Select to an Update query.
However, the whole method worked perfectly well before.
Can you explain to me the cause of this error?
2- The original developer did not necessarily use best practices for the design of the application (no autonumber, some tables without primary key, no foreign keys) so I'm afraid that a new design will need to be done if I migrate to a SQL Server database. Or maybe to save time, as this solution is going to disappear in 18 months, I should only replicate the bad practices in SQL Server and pray that it does not cause any more glitches. What would be your professional approach?
Thank you
There may be none. Open the database in Access 2019/365 and save it in the 2007 (accdb) format, and check it out.
As for the distribution, you can make this fully automatic using a script and a shortcut. It is explained in full in my article:
Deploy and update a Microsoft Access application with one click
If you don't have an account, browse to the link: Read the full article.
Push hard to get a confirmation on the move of all the shared tables to an SQL Server backend.
A few things:
To update your mde or accDE front end? That is a simple copy to each workstation. You don’t need to re-install the runtime each time. There is no “special” connection between one particular application (mde/accde) that you deploy to each workstation.
In other words:
If you writing software in VB6, then you need to install the VB6 run time (but only one time). After that you can simply copy + deploy your application to each workstation.
If you writing software in say .net then again, you have to ensure the correct .net framework is installed on each computer. Once done, then again you can update your software by a simple copy to each workstation.
And the same goes for using the access run time. Once installed, then you can simply copy any mde/accDE to that workstation, double click on it and it will run. So the run time is not connected to any particular database you copy to the workstation. Once you have the runtime installed, then you can rather easy cook up some automatic update code for the front end to "check" some version number, and then copy down the new updated front end. There are quite a few ways to do this - even a simple batch file can often suffice here.
So in near all cases these days, you will have to do “one time” install of the required run-time and support libraries. This is the case for .net, older VB6 programs, or Access.
As for migration of the access table data to SQL server?
You should be able to simply migrate the table data to SQL server. Now link the application tables from the older access back end to SQL server.
At this point, 99% of your VBA and even DAO recordset code should work just fine.
There is no need (or even a good reason) to dump using DAO code you have – it should work as before with VERY few modifications.
About the only change is for code that does this:
Dim strSQL As String
Dim rst As DAO.Recordset
strSQL = "select * from tblCustomers where City = 'Edmonton'"
Set rst = CurrentDb.OpenRecordset(strSQL)
' above for SQL server becomes:
Set rst = CurrentDb.OpenRecordset(strSQL, dbOpenDynaset, dbSeeChanges)
And you can even migrate the tables with indexes, and table relationships intact by using the Sql Server Migration Assistant for Access (SSMA). You can find this fantastic tool here:
https://www.microsoft.com/en-us/download/details.aspx?id=54255
So, about 99% of existing forms and VBA code will work as before after you migrate the data to SQL server.
We are maintaining Microsoft Access 2016 database for Locker Management Inventory. The database contains complex queries (Computed Columns) , Reports and Database backend file is also on the same computer.
We are required to use SQL Server Management Studio 2012 as our Back-end for Microsoft Access Forms and this form is required to be accessed by 10 Users on LAN. Please guide Step by Step Procedure for this task.
Thanks in Anticipation.
Access is inherently multi user and has no problem linking to tables on a SQL Server that is on the same LAN.
The design steps are typically to design the application in Access, unsplit, in a single file. Then when the app is ready - one splits the file into a back end and front end that are linked. One can copy the front end multiple times for multiple users.
These steps above are all Access and you'll find good documentation online and in any textbook for the Access database.
The final step, if one must use SQL Server as the back end, is to then import those tables from the Access back end file into the SQL Server. This is not uncommon but the instructions for this would be in SQL Server area.
Hope this helps.
One must understand the fundamental architecture: a multi user Access application is 2 files: front and back (this is actually what they are called). There is only 1 back file - it is where the tables are held. The front file can be copied repeatedly, 1 per user, and all fronts link to the single back end file.
SQL Server is the back end and Access is the front end - in your case.
One only really needs the SQL Server product as the back end file if the payload is particularly high. Pay load is combination of the quantity of records and simultaneous users.
The basic approach is to split your database into two parts. A built in database splitter is built into Access. Once done, you could in theory just place the back end accDB access file on some server folder that is shared to everyone. You then use the linked table manager in Access to link to the back end file.
Since you been “mandated” to use SQL server, then you would migrate the back end accDB file tables to sql server, and then re-link (again use the built in table manager) to link the tables to SQL server. So the process for linking to an access file, or linking to sql server is near identical. The end result is your access application will now be using tables that reside on SQL server. From a developer and even user point of view your forms, code, reports etc. will continue to run as before.
And as a general rule it only makes sense to run SQL server on your machine for development use. You would have to copy/transfer the sql database to that “mandated” instance of SQL server they are telling you to use that presumably is running on some server. It would not make sense to mandate use of SQL server without you being provided with some server running SQL server.
It certainly is possible to allow users to connect to YOUR computer running SQL server, but that seems less than ideal since if you re-boot, shut down or your computer freezes, then all other users would suffer a connection break and much inconvenience.
I mean, right now if you have a shared folder for all users, such folders are typically NOT placed on one users computer, but some dedicated machine that acts as some kind of server for everyone.
So if they are telling you to use SQL server, then it quite much assumed they are providing a dedicated machine that is running SQL server. So certainly for development you can (and even should) run SQL server on your machine. However you would then have to transfer that database to the computer/server they are telling you to use with SQL server. And then you would re-link your Access application tables to now point to that production server. The last step would be to then distribute this correctly linked application to each user. So just like all software you purchase such as word, or Excel, you STILL install that software on each computer. Now that you are building software, then you as a developer will adopt the same concept – that is to distribute and install your software on each workstation. So while you might use word or Excel (or Access) from the local computer, you also may well often “share” some data files (but NOT the application) on the server.
As long as the application you distribute to each workstation is correctly linked and points to the server based edition of SQL server, then you all be sharing the same database. You will NOT in practice have multiple users working on and using the application you created, but distribute that Access application to each workstation. How you “get” that application to each workstation is not really any different then how you would supply a word document or Excel sheet – the only requirement here being that each workstation gets their own copy. Since each users copy of this application has linked tables that point to SQL server, then you all working on and sharing a common database.
So the first concept to grasp is that of spitting a database. I explain this concept here:
http://www.kallal.ca/Articles/split/index.htm
As for some steps and migrating to sql server, here is a great starting point:
https://www.fmsinc.com/MicrosoftAccess/SQLServerUpsizing/index.html
I've recently been hired on as an intern to take over a previous intern's Access 2003 Database. I have no prior experience in Access, and only a fundamental understanding of relational databases/SQL.
I'm looking to make the database faster, and more secure. Right now it's split on the network drive, with the backend database in a subfolder within the main project folder. It's being used by around 70 employees to take tests and store certifications. Several admins use it to create and print these tests.
It's extremely slow. The files are currently stored on a server several states away. If I transferred this database to Sharepoint, would it be faster and more secure? Is it worth the time and effort to do so?
The employees that use this database currently access it from a .exe on their desktop. Would sharepoint be more user friendly for them?
Alternatively, would moving the .mdb files to a closer server solve the speed problem? I'm currently using Access 2010. The forms are painfully slow to use as of right now.
Thank you
Moving the files to a local server would alleviate a lot of the speed concerns. Moving the file to SharePoint wouldn't do much different in terms of performance. But I'm assuming the files aren't local already for an unstated reason? Ideally, it should be moved to MS SQL server if you want to move the database, but that requires MS SQL knowledge.
Moving to SharePoint will only work if you up-size the data tables to SharePoint lists.
You cannot place the Access mdb/accDB file on SharePoint in some shared folder and have multiple users update at the same time. The reason of course is SharePoint files cannot accept “partial” writes. You have to "pull whole" file to client, update, and send whole file back. So this is not a possible setup with Access.
Access requires in multi-user mode that individual users can update “ONLY bits and parts” of the file at the SAME time. When you place a Word or Excel or in this case an Access file on SharePoint then the WHOLE FILE must be downloaded to the client. User then edits and then saves the file back up to SharePoint. So SharePoint is whole document based not file based like windows is. There is no NTFS file system - only a web based up/down file system (very much like FTP).
So SharePoint is a web based interface and Access requires the windows networking system + ALSO the ability to update bits and parts of the file (something SharePoint does not support nor any web site for that matter).
However if you move your back end tables out of Access and up-size the data to SharePoint tables (lists), then the Access front end clients can connect + edit that data. This is not much different in concept of up-sizing the data tables to SQL server.
So Access front ends can connect to an Access back end on a file server (your current setup), or connect to SQL server tables, or connect to SharePoint tables.
I explain how to up-size data tables to SharePoint in this video:
https://www.youtube.com/watch?v=3wdjYIby_b0
In some cases Access to SharePoint tables will run absolute circles around Access to SQL server. However in other cases such a setup will run SLOWER then SQL server. Only an experienced Access developer on a case by case basis can determine if SharePoint tables would be appropriate for your application. As the other poster points out adopting SharePoint or SQL server will require experience with those technologies along with likely a few good years of Access experience. Remember Access has a rather long learning curve – in most cases longer then say learning c++
In your case due to the Wide Area Network (WAN), then I suggest terminal services is your best bet.
I explain in easy to grasp terms as to why your setup now is slow in this article and what solutions you can adopt:
http://www.kallal.ca//Wan/Wans.html
I am having to develop an application very rapidly. I have chosen SQL Server (2012) as the DB backend, and I will write all my stored procs, triggers etc in the backend.
However, for UI (logon, reporting etc), I am using Access 2010 for the frontend. I am new to both Access used earlier versions of Access waaay back in the day) and SQL Server (familiar with other Db's).
The goal is to have the database reside on a server and let clients connect with an instance of Access 2010 running locally on their machine.
I am looking for a quick tutorial that shows me how to use the SQL server objects from the Access frontend (I believe its called linking) - any link to useful resource would be very helpful, as I can't seem to locate anything useful (I may searching using the wrong keywords).
Assuming you built all the tables and data on SQL server, then in Access it is a simple matter to link Access to that database.
And to save development time, you can continue to use the Access simple approach of using forms bound to those tables. As long as you launch a form with some kind of criteria (say an invoice number), then that bound form will ONLY pull down the one record from SQL server into that form. (so need to write or use store procedures etc. for that form). And any triggers etc. you have built in SQL server will run without you having to do anything from the Access side.
So a plane jane form build in Access that is bound to a table of say 1 million rows in Access does not need any “special” code – just make sure you launch the form with the “where” clause that Access provides and the form will only pull + load the one record.
So 99% of the normal development process you used in Access in the past will continue to work. Using SQL server for the most part does not change much if anything in regards to building forms that edit such data.
However, for reports and some forms that query + search for data etc., or some VBA code that needs to “process” data, you are most free to call store procedures. You simply create a pass-through query in Access. The VBA code to use that T-SQL thus looks like this:
Currentdb.QueryDefs("MyRawt-sqlPassThoughquery").Execute
Or
with CurrentDb.QueryDefs("MyPass")
.SQL = "exec sp_myProc"
.Execute
end with
In the past for most access applications you likely used liked tables – those linked tables can be to a Access file (back end), or Oracle, or SQL server – how the actual application works and functions is really much the same for all cases. (so there not really a lot of “specific” things you need to know from the Access side – if you comfortable with Oracle, or SQL server, then using Access as a front end works just fine, and the typical development approaches used in Access will remain typical.
Here is an article that outlines the linking process:
https://support.office.com/en-us/article/Import-or-link-to-SQL-Server-data-A5A3B4EB-57B9-45A0-B732-77BC6089B84E?ui=en-US&rs=en-US&ad=US&fromAR=1
Keep in mind you will see MANY articles that talk about ADP projects - they have been deprecated since Access 2010, and I don't recommend using ADP projects with Access - so be careful, since many articles that talk about Access + SQL server are built around ADP projects which as noted should not be used anymore.
This office.microsoft.com article should give you a good overview.
With plenty of more technical information searching for "query sql server from ms access".
Don't mess about with linked tables. Use an Access ADP (Access data project), which is natively connected to SQL Server. Sadly this type of access file is being phased out but it is the optimal solution for an MS Access front end with a SQL Server back end
Pros and Cons of Access Data Project (MS Access front end with SQL Server Backend)
I have two applications with own database.
1.) Desktop application which has vb.net winforms interface, runs in offline enterprise network and stores data in central database [SQL Server]
**All the data entry and other office operations are carried out and stored in central database
2.) Second application has been build on php. it has html pages and runs as website in online environment. It stores all data in mysql database.
**This application is accessed by registered members only and they are facilitied with different reports of the data processed by 1st application.
Now I have to synchronize data between online and offline database servers. I am planning for following:
1.) Write a small program to export all the data of SQL Server [offline server] to a file in CVS format.
2.) Login to admin Section of live server.
3.) Upload the exported cvs file to the server.
4.) Import the data from cvs file to mysql database.
Is the method i am planning good or it can be tunned to perform good. I would also appreciate for other nice ways for data synchronisation other than changing applications.. ie. network application to some other using mysql database
What you are asking for does not actually sound like bidirectional sync (or movement of data both ways from SQL Server to MySQL and from MySQL to SQL Server) which is a good thing as it really simplifies things for you. Although I suspect your method of using CSV's (which I would assume you would use something like BCP to do this) would work, one of the issues is that you are moving ALL of the data every time you run the process and you are basically overwriting the whole MySQL db everytime. This is obviously somewhat inefficient. Not to mention during that time the MySQL db would not be in a usable state.
One alternative (assuming you have SQL Server 2008 or higher) would be to look into using this technique along with Integrated Change Tracking or Integrated Change Capture. This is a capability within SQL Server that allows you to determine data that has changed since a certain point of time. What you could do is create a process that just extracts the changes since the last time you checked to a CSV file and then apply those to MySQL. If you do this, don't forget to also apply the deletes as well.
I don't think there's an off the shelf solution for what you want that you can use without customization - but the MS Sync framework (http://msdn.microsoft.com/en-us/sync/default) sounds close.
You will probably need to write a provider for MySQL to make it go - which may well be less work than writing the whole data synchronization logic from scratch. Voclare is right about the challenges you could face with writing your own synchronization mechanism...
Do look into SQL Server Integration Service as a good alternate.