For a school exercise I had to make a view in MS SQL Server and use it for a report in MS Access.
I've made the view in SQL SERVER, but how can I import it into MS Access so that I can use it?
The SQLServer DB is linked with MS Access.
I have made a form for the previous exercise, now I want to make a Report that gives the data from the view I made. I tried using our reader and google, but they are not giving the answer I need. It seems something very simple I am missing out. Just don't get how to update the DB in Access or something, when I make something in SQL Server, it doesn't get added to Access automatically even though I linked them..
Related
History of issue. A colleague built an access database and using VBA made a connection to SQL Server. Then running VBA code made a global temp table ##tablename. this information is used in a passthrough query in the database.
I had to build a new database that uses the same logic. I have everything working except that first part. I am missing something in my code and I am not using code correctly to make that SQL Server connection and run my create global table.
I am not too familiar with this part of coding. I am going to need some hand holding here. I am getting errors no matter what I try.
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 want to know how to convert an Access database file into a SQL Server (.mdf file) database?
The MS Access "Upsize Wizard" was discontinued with Access 2012. SQL Server Migration Assistant (SSMA) is now recommended. Reference: https://accessexperts.com/blog/2013/01/30/access-2013-is-here-but-wheres-the-sql-server-upsizing-wizard/
However, as Johnny Bones noted, I found it relatively easy to create a new empty SQL Server (2012) database and then import:
SQL Server Management Studio, R-click on the newly created Database | Tasks | Import Data -> SQL Server Import Wizard
I used "Access Database Engine" instead of "Jet Database Engine" for
no reason other than I GUESSED Jet was older. Mine is a throw-away
project you may want to research the difference.
I 'weeded out' the
Access queries (views) and just imported the tables.
So far it looks
like everything was imported OK.
The simple answer is; you can not "convert" an Access database to a SQL database. You can, however, import the Access database (tables only) into SQL. Remember that SQL is a true database, and, as such, contains no front end or GUI creation mechanisms. You will still need Access (or C# or VB or another front-end builder) to create the interface.
You may already know this, but in SQL Server a Query is called a View, and Modules are called Stored Procedures. You will need to convert your Access queries and modules accordingly if you're planning on having that all reside server-side.
It's actually pretty easy to import Access tables into SQL Server, you would just create a database on a server, right-click on the database name and choose Tasks --> Import Data. There you will choose Microsoft Access as your Data Source. The rest should be pretty self-explanatory.
JonnyBones wrote a good full answer. Other have made suggestions for tools which may work. However, the SSMA (SQL Server Migration Assistant) is likely to be the best option now. (See this youtube video for help with understanding some of the issues to overcome and an explaination of how to use SSMA.
Befre you consider using other tools, which may do more, you should find out why to use them instead of SSMA. Check out the youtube video as a starting point.
Be aware that the MS Access Upsizing wizard was great but is now discontinued, and there was a bit of a gap before MS created a decent version of SSMA, which is when&why these other tools came into existence.
SSMA should do what you need.
There are some access things that do not get moved to SQLServer and some that do.
eg Access triggers do not. Access tables constraints do, Access boolean datatypes so - of sorts - but you need to do some work. The video will explain most issues well.
Harvey
You can try with the Upsize Wizard or copy content of the table from SHOW TABLE DATA and paste to the target table with the same structure as the source.
I'm writing an inventory/payroll system, and I'm storing all the records on a remote server running SQL Server 2005 on Windows Server 2008 R2. I was wondering how I could start writing forms(very basic) in MS-ACCESS 2010 to upload things to the database. I just want to test it out to make sure that once I implement the entire database, things will work smoothly and without error. I want to figure out how to just make a single form that will be connected to the database, right now the form will just be a simple single text input with a submit button, that will be uploading barcodes(strings not images).
If I need to clarify anything, please just ask.
Thanks in advance for any help
Microsoft has tons of useful "Getting Started" articles.
This one explains how to connect to SQL Server: http://office.microsoft.com/en-us/access-help/import-or-link-access-to-sql-server-data-HA010341762.aspx
This one covers all sorts of forms: http://office.microsoft.com/en-us/access-help/CH010369205.aspx
Go there, you will find a lot that can help you with whatever you are going to do.
Make sure you have the SQL Client driver installed on the workstation where you'll be using MS Access. You can download it here (look for sqlcnli).
The simplest way to get started is to build an ODBC DSN. Access can then link to your SQL Server tables using that DSN. How to Create a DSN
In Access, Go to the "External Data" option and choose ODBC. Locate your DSN and then select which tables you want Access to be linked to.
After your linked tables are showing up in the tables list, click on one of the tables, go to the Create tab (2007, not sure about 2010) and choose Form. This should automatically create a form for you using the table you had selected when you clicked the Form button. There's no need to write code or add buttons to this form. The default form can do all CRUD operations as long as permissions for all CRUD have been granted to the username you used when you created your DSN.
Some developers prefer to use ADO (code only, no linked tables or form wizards) or Pass Through Queries to access SQL Server from Access. I can't really tell you what you should be using because it depends on so many different factors including (but not limited to) size of project, amount of records, skill level, personal preferences, etc.
I've seen lots of questions regarding moving data from Access to SQL Server, but I'd like to go the other route. Here's why:
I've been working on a sizable project with a SQL Server 2008 back-end and Access 2007 front-end. I'd like to be able to do some work on the front-end from home over the weekend, but I don't have access (VPN or otherwise) to SQL Server from there. I'd like to change my linked tables from SQL Server to another Access database file where I imported a snapshot of the SQL Server data. Then, come Monday morning, switch links back to SQL Server.
My problem is when I go to the Linked Table Manager and attempt to change the link, all I get is the ODBC Select Data Source dialog. If I try to link to an Access database, it tells me ODBC can't be used to link, import or export to another Access file.
One thought has occurred to me but I haven't tried yet; maybe someone could tell me if it's a good or bad idea: would I be able to delete the links, re-create them to the other Access file, and not lose any functionality in my queries/forms/reports?
My proposal would be to have SQLExpress (free) installed on your computer. You can then have all the data available on the machine. Create a publication on your main server, and have your local machine suscribe to this replication (if you don't need to save/synchronize the data changes done on your machine, you can stick to a basic 'snapshot' replication.)
You then just have to change your connection string from your network MSSQLSERVER to your localhost SQLEXPRESS server instance to have your app work.
If, for any reasons, you have to make changes to the database model while being off-line, you will then have to unsubscribe from the main server before making the changes on the local server. When you're back to the office, make sure that the same changes are done on the main server. My advice is to write your changes in T-SQL, save them in a file, and launch the file against the main server once you're back to work.
My opinion: don't work too much on weekends, or make sure your client is being billed for that.
For linking tables, you need to delete them and entirely and recreate them. Using the linked table manager to refresh ODBC links doesn't even work reliably when you're still using ODBC, as there is data cached in the table link definitions that doesn't get refreshed (e.g., if you change the number of columns in a SQL Server view, refreshing the table link with Linked Table Manager will update the number of columns, but you won't necessarily get an updateable view (assuming the original was updateable)).
But it's not clear whether or not you'll lose functionality or not. That all depends on how much of your application's logic is server-side, in SQL Server views and stored procedures. None of those will work if you link to a Jet back end.