I have an old Access application that has a lot of code in forms and reports. The database is getting too large and I am thinking of moving the back end to SQL Server.
My requirements are as follows:
The DB needs to be multiuser and the users (3-5) will need to log in over the web
I would prefer not to re-write the forms and reports in ASP or some other web front end.
When I think about my choices, I see them as:
Have an Access ADP front end and allows remote log-in to the server where it is stored. Not sure if it is possible for 2 users to simultaneously log in
Distribute an ADP front end to the users, but I am not sure if it is possible to connect to a SQL Server back end over the internet, and the network traffic may be an issue.
Any other solution?
I appreciate all help.
u
I would recommend against rewriting as ADP (you do realize, I hope, that you can't convert an MDB to ADP?). ADP has been deprecated by MS for about the last 5 years, and has received no development attention in the last two versions of Access (A2007 and A2010). It may get some attention in the next version of Access, or it may be dropped (as was the case with DAPs after two versions of no changes).
The easiest way to roll out multi-site access to an Access application is with Windows Terminal Server. This is extremely easy to implement and not all that expensive and requires no alterations to your Access application (I assume you'd upsize the back end regardless, of course).
You also might want to familiarize yourself with the fabulous new features of Access 2010 that integrate with Sharepoint Server 2010 and its new Access Services to allow the development of an Access app that runs almost identically in the Access client and in a web browser (via Sharepoint). This would require a major rewrite, of course, but it's also quite scalable.
It's also the future of Access, so far as I can see, and will be getting lots of attention from Microsoft over the next few years.
I work on a clients MDB FE on a VPN/ADSL connection to their server. It's slightly more sluggish in some areas than working in their office. But it does work well. So I see no need to convert the app to ADP format.
Note that they've done a lot of work creating views and stored procedures to greatly improve performance.
There is a tool from the SQL Server group which is better than the built in Upsizing Wizard. SQL Server Migration Assistant for Access (SSMA Access)
Also see my Random Thoughts on SQL Server Upsizing from Microsoft Access Tips page.
The only secure way to expose a sql server back end to and access front end over the internet is over a vpn. Unless you rewrite queries and other sql in the access code to execute queries on the sql server, sql server is probably going to transfer entire tables to the acccess front end forprocessing and filtering which will be slow over a vpn. If you really don't want to have to recode i think rdp acess is going to work best.
ADP is definitely faster over a WAN than linked tables. Linked tables are the least efficient thing in the world. Jet didn't get any new features for 10 years.. Access Data Projects get new features through every release including Access 2000, 2002, 2003, 2007 and 2010. ADP has also gotten new features in 2005 and 2008 with the release of SQL Server. ADP has gotten new features with every release, it is NOT depecrated, it is fully supported. There are specific hotfixes released for ADP just like there are for Jet.
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 have an Access 2016 database with lots of tables, forms and reports from a client. The client would like other people to access the data in this database but doesn't want to spend the money to convert the forms and reports to a website. They would rather have Access 2016 as a frontend with it's forms and reports and store the data in a centralized location. The issue is the users who will access this data won't be on the same LAN or network.
The solution I came up with was to use SQL Azure as the database backend and keep the forms and reports in the Access 2016 database frontend. Can anyone think of an alternative? Does Microsoft have some kind of online hosting with Office 365? I have nothing at all against SQL Server and use it frequently but just don't want to go through the effort of upsizing the database when a simpler solution existed.
You can certainly place the back end on SQL Azure. However given that a typical internet connection is about 100 times slower, then MUCH effort is required to optimize the application. So you need significant experience on how to optimize an Access application to work with SQL server. This setup is thus doable, but will take significant amounts of work to achieve decent performance.
Another possible solution is to use a SharePoint or office 365 back end (which supports SharePoint tables). This setup only works well if table’s sizes are in general below 5000 records. You also have to ensure all table relations are standard auto number PK and child tables use a standard long number column to relate back to the parent table.
Likely the best solution is to setup a server and run remote desktop. This gives the best performance, and the end users don’t need to install access nor your front end part.
I explain in detail the “slowness” with using SQL server over the internet in this article of mine along with some suggestions and possible solutions.
http://www.kallal.ca//Wan/Wans.html
Currently, I'm developing a C#-based program for a small rental company (3 locations). Right now, they use MS Access 97 (Jet SQL based) as database and I wish to upgrade this. However, I do want to keep Access as Front-end, since I will be gone after the development, and the local personnel knows how to use Access (some changes require direct editing in the database).
I am doubting between two options:
Upgrade to Access 2013, therefore using MS ACE as DB engine
Use SQL Server Express with Access as front-end, therefore using MS SQL Server as DB engine
The system will have one shared database and one for each location. They are using a shared drive for this (they work on MS Server 2008). Their databases are pretty small (< 1 GB combined), so I won't need the extra performance e.g. MySQL provides. I know the difference between ACE and SQL Server in terms of design (File-sharing vs client/server), but I still don't know what would be better suitable for this situation.
What is the better option here when looking at performance, reliability, security and connection to the application?
Thanks in advance.
As #granadaCoder points out, the security, performance, reliability of using SQLExpress is far better than Jet and ACE and is just as easy to connect/link to your Access 97 front-end. Microsoft provides a free migration tool that is very powerful and easy to use.
Converting an MS-Access 97 application to 2013 may present some real challenges as Cwell. onverting from Access 97 to 2013 is a two step process. You must first convert it to 2002-2003 and then to 2007/2013. You will also need to purchase licenses for all users and the back-end database.
In addition, if your 97 application references external objects, they may not work with later versions of Access.
As #granadaCoder also suggests, a good medium to long term plan would be to convert the front-end to .NET.
Microsoft Jet is just a file sitting on a network drive.
So when you do queries......the Jet-Runtime (on the local PC) has to bring large chunks of data (entire tables) across the network.
Thus it is brutal.
Sql Server (Express or Other)....runs as a service on a host computer. And when a query is executed, it does processing on the Server and returns "smaller buckets of information".
(Which you mention knowing the difference between file-sharing vs client-server).
If you cannot give up your Access(the program) front end...then doing link-tables to Sql-Server would be you best bet, IMHO.
Well, I'm talking from performance.
Security, you have more options for different users and passwords. And you can slice up which logins/db-users are allowed to do what.
IIRC, a Jet database allows one password. Aka, all or nothing.
https://www.connectionstrings.com/ace-oledb-12-0/with-database-password/
That alone would make me go with SqlExpress.
..
The big early design decision was to use Microsoft-Access-Forms. You're paying the price for that early decision.
Even when people use a Jet-Database, I would only use it for basic data storage. And put a Layer .Net application on top of it. Then a swap out to a different data-store isn't as drastic.
Good luck dude.
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)
A colleague I work with recently told me that SQL Express and MS Access were essentially the same thing; that does not seem to be an accurate statement. I know you can convert Access to a SQL DB and maybe under the covers they are similar, but I would assume that the SQL DB engine and what is used to run access are not the same. Not only that, but the SQL statement syntax, etc. I know are not the same.
I am mainly trying to understand so that I am more informed about the versions.
Um, no, not the same.
First off, I need to clear up some terminology. MS Access is a Rapid Application Development (RAD) tool that allows you to quickly build forms and reports that are bound to relational data. It comes with a file-based database engine (Jet/ACE).
Access the RAD tool can be used with many different backend databases (Jet, SQL Server, any db that supports ODBC, etc). I have to assume your colleague was specifically commenting on Jet/ACE, ie the database engine that MS Access uses.
I think the single biggest difference between the Jet/ACE database engine and MS SQL Server Express is that Jet/ACE is file-based and SQL Server Express uses a client/server model. This means that SQL Server Express requires a running service to provide access to the datastore. This can complicate deployment in some scenarios.
SQL Server Express is really just a throttled-back version of SQL Server: max database size of 4GB (10GB in 2008R2), only uses a single physical CPU, etc. These limitations are imposed to prevent large organizations from using the freely available Express edition in place of a full-blown SQL Server install. The upshot to this is that SQL Server Express offers a truly seamless upgrade path to SQL Server. It is also (generally speaking) a more robust and fully featured database management system then Jet/ACE.
Similarities
relational database management systems
written by Microsoft
Differences
MS Access
File based
free distributable runtime (2007 or later)
RAD tools (form/report designer)
uses Jet SQL
max file size 2GB
SQL Server Express
Client/Server model
free
no RAD tools
uses Transact-SQL
max database size 4GB (10GB for SSE R2), max one physical CPU
I think what your colleague had in mind was SQL Server CE, which is a super-lightweight embedded database, which is still (IMO) far superior to Access in database-management aspect. SQL Express cannot even be compared with Access without offending the former.
Here are the datasheets for both products so you can see some hard facts on the difference between the two databases.
Access:
http://office.microsoft.com/en-us/access-help/access-specifications-HP005186808.aspx
SQL (Express is listed on the far right column):
http://www.microsoft.com/sqlserver/2008/en/us/editions-compare.aspx
The comment I have always read is that Access is great for single user single access database use, the minute you scale beyond a single user look elsewhere. While that may be a "bit" of a stretch, Access really does not do well in a multi-user environment. From experience we've had a client who has ignored and ignored our requests to migrate a backend database from Access to SQL, and there have been numerous occasions where we have had to restore from backups, or take the Access database offline due to corruption.
They are two completely different technologies with two different target markets. The database engines are indeed different, as you mention T-SQL is different than Access SQL.
You can "scale up" an Access database to SQL by creating an SSIS package or other tool to do the import, but this takes the Access schema and data and migrates it to a true SQL database. It does more than just attach the Access database or the like.
Anytime you need a "real" database I'd highly recommend looking at any of the SQL versions that are available over Access.
Just remember that with MS-Access you don't have size limitations if you play your cards right. There is no reason, for example, not to have many 2 to 4 Gig tables each contained singularly in their own database. Your ODBC applications can open a connection to multiple MS-Access databases and query the single table in each. So you can have a database containing trillions of records, stored in multiple MDB files. One company I went to work for was using a single MS-Access database to run a issue tracking system done in MS-Access forms. They could only use it one person at a time because of sharing issues that would lock MS-Access up. I wrote a Win32 Perl native Windows GUI user-interface to the database that was better at field/record validation, and my ODBC code was able to manage the connection for simultaneous user access. I managed the opening and reading and writing and closing of the database for each user through my Perl program. I did not leave the database open. I did not maintain a persistent connection for each user, but instead only maintained a connection long enough to retrieve a record for edit. Then I closed the connection until it was time to write the record back to the database. Also, I wrote my own record locking program logic by maintaining a user login table that contained the record id of the record a user was currently editing, then erased that entry when no longer editing that record. When another user went to edit the same record, the program checked if that record was currently open for edit by another user. The system worked flawlessly. MS-Access never locked up via ODBC and multi-user access. I even embedded the password to the database in my compiled Perl program so that no one could get to the data in the Access database other than through my Perl program.