Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I want to clarify what I do understand first.
We can store data on MS Acess itself but doing so will make the
database usable in only one computer where the Access table is. This makes it difficult to share data
We can create a SQL server to store database
My confusion is on some of the technicalities of the SQL server part
Is ODBC just a connector for Access and SQL sever?
Does VBA code differ if we have SQL server or not?
Difference between SQL Server Management Studio vs ODBC database vs SQL Server
First, on what you do understand:
You can place the Access database on a network share, so it can be used from different computers.
You can also place an Access database file containing just the tables ("the backend") on a network share and use linked tables in several "frontend" database files.
Now, on the things that confuse you:
ODBC ("Open Database Connectivity") is a standardized technology that allows applications to access data from various sources. You can use an ODBC driver (for "SQL Server" in your case) to allow an Access frontend to work with data stored in a SQL Server database. The database tables from the backend can be linked into the frontend (as "linked tables") and then be used in the Access forms and reports just as if they were tables in the Access database.
You will most probably not need to change your existent VBA code when using "linked tables" (unless you use some functionality that applies just to local tables). But for sure you can change some code or even move some routines into the backend database (as "stored procedures") and call them from your VBA code to improve performance.
"SQL Server Management Studio" is a tool (the tool from Microsoft) that is used to manage all kind of objects on a SQL Server (databases, tables, views, stored procedures…). Also, it allows you to write and run SQL scripts and single SQL statements (like queries). It is a graphical user interface so manage SQL Server instances and everything that belomgs to databases using table or query designers, data grids and several property windows.
"SQL Server Management Studio" can be seen as a frontend, too, because behind the scene, it uses SQL commands to communicate with SQL Server. To manage the communication between the frontend "SQL Server Management Studio" and a backend (a SQL Server instance), it does not use ODBC but a newer technology named OLEDB.
Related
I have an ACCESS database that I'm using to test migration to SQL Server. It has one local table; no linked tables, forms, queries, or reports. One site said to use the open the Database Tools tab, and click the Access Database icon in the Move Data group. When I do, it tells me that the database must be split. How do I let ACCESS know that the database has been split?
The move data features up to Access 2010 ALSO had a feature to move data to SQL server. However, due to SQL server always changing and having new versions that come out at "different" times then ms-access?
the feature was deprecated, and versions of Access after 2010 don't have the move to sql server anymore.
If this is just say a simple single table, then it you can use SQL server studio to import the table. (but, you lose PK settings, and indexing, and relationships (assumes you have more then one table and related tables).
If you looking to migrate a lot of data, and a lot of tables?
Then it is high recommended that you use the Sql Server Migration Assistant for Access. (SSMAA).
It is a separate download. You can find SSMAA here:
Information on this tool, and download links can be found here:
https://learn.microsoft.com/en-us/sql/ssma/access/sql-server-migration-assistant-for-access-accesstosql?view=sql-server-ver16
While the tool has a learning curve, it is well worth the efforts for any type of serious data migration from Access to SQL server.
I need to update an MS Access app that connects to a SQL Server database. I copied the app and SQL database to my development computer, opened Access and linked the tables (100+ of them). I can see the data via Access, but all of the table relationships are lost, and the forms are giving me 3146 connection errors.
How do I straighten out the data so I can add features to the app (and eventually give the app to the client to reconnect with the original SQL Server)?
Complication: I haven't used Access in 15 years, so I'm a little rusty with it...
The relationships are NOW handled by SQL server. They have ZERO to do with Access, or a web site, or VB6, or some .net program that simply connects to SQL server. The .net program, the VB6 program, or the software you develop using MS Access has zero to do with how the relationships are setup with the given database system (in this case SQL server).
So that web site software, or .net program, or even MS Access does not change, or control the relationships you setup on SQL server. If this were the case, then which of the programs such as .net, web site, VB6, and MS access all using the SQL server at the SAME TIME would control relationships then??
So it is not possible or practical to have the client software control or set the relationships used by SQL server, since then it would be the client software controlling this, and every program that connects to SQL server could then be different!!! (and thus no enforced relationships would be possible as all programs would have differing ideas as to how the relationships are supposed to be!!!).
Any relationships settings you have in Access are thus ignored by SQL server, since it is now SQL server that is managing the database – not Access.
Access is just a developer’s tool like VB6, or say vb.net – those programs are free to connect to SQL server. Since many different programs are able to connect to SQL server, then the programs connecting are not the ones that control relationships – it all has to be done and set on SQL server.
Access will still allow you to use the relationships diagram. You can thus still draw out relationships in that window if you want, but you note how the options to “enforce” the relationships are now gray out – they can’t be used. So it still can be a documentation tool, or a means to make a cute diagram, but as such, it will not affect the operation of SQL server.
As for you errors? Well, before you attempt to open any form, you want to click on a linked table, and see if that works first. No use to try code, forms, reports if you not FIRST sure that the table links are active and working. ONLY until such time that you can click on, and open a linked table should you be concerned with trying to use forms, code, reports etc.
I would suggest you use the linked table manager, and re-link the tables. Now, I suppose you could delete the links, but I do NOT recommend that as a first try, since the table names will likely have a dbo prefix in front of them, and this will result in all your table names being changed, and that will break near everything in your application. So really try the refresh approach, since if you have lots of tables, then you have to re-name them all if you delete the links and re-link (so try to avoid my suggesting to delete the table links and recreating them – it will save a lot of work).
So first step:
Make sure the table links works. (don’t try code, don’t try forms, don’t try reports).
You need to ensure that a simple linked table works, and that you can simply open these linked tables. Skipping this step means everything else you attempt is folly and a waste of time.
So click on a linked table and see if you can then open + view that linked table data.
If not?
Then I would launch the linked table manager, and select all linked tables, and then force a re-fresh. (make sure you click on the box to [x] “Always prompt for new location” in the lower left corner of the linked table manager.
For my company there is a report that ends up in an access database format (.accdb) when it gets to my department. We want to deploy an SSRS with this information. While I was able to do it in Visual Studio the database manager questioned whether this can actually be deployed and work in the server environment. Can this this be achieved?
Are you talking about an Access report, or data inside of Access?
SQL server reports are not built in Access and have absolute nothing to do with Access. The only issue would be then since the report cannot be built in Access, then why attempt to have SQL server open an accDB file for the data source? You would be much better off to simply have Access transfer the table data to SQL server and then continue to use the reports built in SQL server.
So a report in Access has ZERO relationship to SQL server reports. As such, the reports in Access are of no use and if your plan is to use SSRS, then the reports have to be built in SSRS.
It is possible to place an Access accDB data file on the server and have SQL server connect such data, but it generally does not allow or work well with multiple users.
Keep in mind, the reverse is certainly possible and often recommended. You place and keep all data on SQL server tables. You then link the Access application to SQL server. In this setup then the data ALWAYS resides on SQL server, but the reports are in Access. And the general forms etc. built in Access will save + send their data to SQL server (and this works without having to write code).
The above thus suggests that the Access application with the reports has to be distributed to users that need such reports. And such users will thus all share only ONE copy of the data since such data resides on SQL server. And this setup would also allow one to create reports in SSRS without having to upload any kind of data, since the live operating data from the Access application always resides on SQL server.
So in summary:
Access reports are Access reports, just like FoxPro reports are FoxPro reports, and FileMaker reports are FileMaker reports. As such, these reports cannot be used, viewed, or utilized by SQL server in anyway.
However, the reverse is not only possible, but is a common solution. Thus the Access (front end) is linked to SQL server and the data tables for forms, code, reports etc. for the Access application now resides on SQL server.
If you place the actual accDB data file from Access ON the SQL server, then SQL server can read the data, but any code, forms, reports etc. from Access cannot be used by SQL server. So a report in Access is of ZERO use to SSRS.
So if SSRS is a goal, then anything built in Access from a user interface point of view cannot be used. SSRS thus can only consume the data in tables.
Since SSRS can ONLY consume data from Access (and nothing else), then a far better solution in place of moving up a accDB file to the server is to simply push up the data from Access tables to a SQL server tables. And if such a data transfer is to occur often, then likely better is to ALWAYS keep the tables and data in SQL server, and have the Access front end part “link” to the data on SQL server. Access reports, forms and even VBA code will in most cases run as before, but the live data always resides in SQL server. You thus eliminate all the dance and song of attempting to transfer data between two systems. The SQL server data is thus always “live” and update to date, and only ONE copy of the table data EVER exists.
Most Access applications and reports and forms can work with very few (if any) modifications when you place the data tables on SQL server, and have the front end Access part “link” to SQL server.
Since a given specialized report in SSRS is going to require a pre-determined and non changing table structure, then the most prudent solution would be to have Access link to and use the data from SQL server tables (not the other way around).
So Access reports can ONLY be used by those with Access (or the free runtime) installed on each client desktop computer. Such Access reports have to be 100% re-built if your goal is to have such reports be used with SSRS.
I am currently working with a company where I am not allowed to install software like Sql server or other data base software but I have ms access or office kind software so
my question is
1> Can we create web based application using ms access and .net based programming language.
(Just to maintain manual based work)
This question might sounds like crazy but I search for it all over internet.Help me
I need to start from beginning...
Connect to MS Access Db
OleDb connection You will use this when reading/writing to the database. It will need to be opened an closed if you're not using an IDisposable method.
Inserting Records to an MS Access Database
Using SQL with c#.net
I'm not sure what language you'll be using, but there are actually plenty of examples using VB/C#.NET.
I'm usually not working with Microsoft products. I have an MS Access 2007 project here, and I know that the MSSQL Server with the Database has some procedures. How can I make them visible? I can just browse trough tables and views...
Thanks and regards,
Jan Oliver
When you say access project, are using the term that you have a project you're working on, or you do specifically mean you're working with an access data project? (ADP). The ms access term ADP has an specific meaning that's very important in your context.
In ms access a good number of developers simply use ODBC linked tables to data is sitting on SQL server. There's also an option in ms access to create what is called a Access Data Project (ADP). When you choose to create an access data project then any view design services such as the relationships editor, table design etc. looks like you're developing inside of the access desktop client, but in fact behind the scenes access is sending DDL (data definition language) commands to SQL server to make those modifications on the server side object. So, you CAN modify server side objects inside of ms-access. No local tables can exist when you create a ADP.
What this means that the version of access and SQL server have to be more closely matched then if you're not using an access data project. If you open up the access database and look in the query table, you should see stored procedures appearing in the list. Access should let you modify them.
So take a look of the file extension, if this is actually an access data project, then the file extension for the access database will be *.adp.
If the file extension is mdb, or accDB, then this is not an access data project, but is a traditional access database in which linked tables to SQL server are being used. This this case of non ADP, then the views and tables you link to will only appear in the tables table. Furthermore ANY design changes you make will be done using the SQL server management tools and NOT the access client. So, changes to tables and views and procedures etc. are NOT made and CAN NOT be made inside of the access client like they can when you're using an access data project. Despite this limitation, most developers prefer using linked tables as opposed to an access data project because of the loose tie between the version of SQL server. In fact you can use even different database servers in these cases such as Oracle or MySql. The other significant advantage of linked (odbc) tables is that the linked tables allows multiple data sources from local files, server based etc. And, you also can have local tables (ADP does not allow local tables in the client).
So your ability to edit or not edit the server side objects inside of access will be determined by the above scenario IF you are in fact using a ADP or not.