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
Related
I have SQL Server Express on a windows server. I have 10 people with MS Access 2016 on the local PCs. assuming that the db is very small and simple. What is the simplest way to connect to SQL Server? Will simple ODBC work? Do I need to enable remote access? TCP/IP? Pipes?
Yes, the basic concept here is to use linked tables. It not clear if before using SQL server, you were using Access in a mutlti-user mode.
The general idea here is you have a split database. So you have the application part or so called front end. This concept is really no different than say running word, or excel. These applications are installed on each workstation. But THEN the application can use some file.
So, in a typical multi-user Access applications, you have your application part installed on each machine (the front end).
Then you will typical place the back end file in some folder on the server. And then your front end will have linked tables to the back end.
If you adopt sql server for the back end? Then the setup is really the same as above. You have the front end application part that you install on each machine, and you have linked tables like before. The only difference is now your linked tables are pointing to SQL server.
So, yes you do have to enable TCP/IP for SQL server. You also have to decide if you going to use windows authentication for the users (that is windows logon). You can really only from a practical use case use windows authentication if you have a domain controller. (A computer that manages permissions to all your computers). If you are not sure or don’t have a domain? Well then you will need to create and use SQL server logons. Most often, you can create one logon/user for SQL server and have all of the access FE use this one logon. (so once again, you link the FE’s using the Access linked table manager, and you use + save this logon during the linking process).
As as a standard approach, how your application will work is really the same when using SQL server or not. In these use case examples, you use linked tables in the front end. In fact if you had a access back end, and now use SQL server for the back end, then all your forms and even the VBA code should work as before. There are often some “minor” changes to code that uses recordets, but the forms etc. should work as before.
ODBC is the simple and proven method.
Sidenote:
Consider the method using a script and a shortcut to distribute the frontend to the users as described in my article:
Deploy and update a Microsoft Access application with one click
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'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
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.
This is probably the most classic database problem.
I have an E-commerce software solution hosted on a SQL server for data, and a web server for the frontend. Every instance/customer has its own database on SQL Server 2008.
During development of the next version, I might change or add tables, views, stored procedures etc.
How do I publish this change to all databases, without losing data? It should be done via a script or something similar. Centralized management is the key...
Perhaps it's something you've already considered, but my company uses software from Red Gate (http://www.red-gate.com/) which compares our development version of the DB and the production one, generates and executes scripts to bring production on par with development.
(I'm not a sales person from Red Gate, but I think this might be what you're looking for)
I use SQL Compare for schema changes and SQL Data Compare for data changes. Works like a charm!
This problem is essentially one of automating the manual process of logging on to a SQL Server, and running a script against one or more databases, that does the modifications you need.
It's made worse, of course, if the instances of SQL Server that you need to update are remote from you, and therefore not directly accessible.
It's also vital to ensure that the scripts are applied in sequence - it would be no point running the "add index" script before the "create table" script.
The way we've solved this is with a web service that packages script files as datasets, and delivers them in the correct sequence to the remote systems when they call home.
On the remote SQL Server, we have a .NET application which calls the web service, downloads the script files, unpacks them and applies them to the database.
When the remote system calls in, it supplies the ID of the most recent upgrade it has. When the web service completes, it knows the last one it delivered. It's therefore trivial to know what level the remote systems are at.
The only manual intervention required is to create the scripts in the first place, and upload them to the central server.
A script should be executed on sql server machine by db admin.
Main algorithm of such scipt is about to create backup, lock table each table in loop, alter it, release.
Another poster mentioned the Red Gate products, and I'll throw another commercial product out there - Quest Change Director:
http://www.quest.com/change-director-for-sql-server/
Disclaimer: I work for Quest, although I'm not in sales. Change Director does comparisons, syncing, links to a change management system, can use your dev/qa server as a source or use T-SQL scripts, has an audit trail and rollback capabilities, etc.
Like you said, central management is key, and this product focuses on that.