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.
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 have three Access database MDB files with various tables I need to upsize to SQLServer. I need to be able to update the data regularly. I am using an SSIS package in Visual Studio. I have it set to use the 32 bit version for this project. I have one of the databases running just fine. Using the same techniques on the next database I create an OleDb connection manager using the Access 16 connection and the connection tests fine, I drop down the tables drop down and it finds the table names just fine. I pick a table and hit ok and it comes back with:
Exception from HRESULT:OxC0202038
I got these databases from another source. Two of the three were set without security. Being older MDB's they have the ability to have user level security. The table in question was in the one database that had security set to admin only. The deceiving part is that the oledb connection could find the table names at all with security set so I should not be able to read them. The ambiguity of the error message was not all that helpful either. But, once I reset the user level security to allow full access things worked fine.
I have a website online with just HTML and I am not willing to use any other programming language apart from Javascript. All I need to do is connect my Microsoft Access database on my computer to a form hosted online so when information is submitted online it is updated on MS access the next time I open the file up. Is this possible and how can it be done?
Turns out, you can do this with zero code. If you use office 365, and publish an Access web forms.
Any information entered into the Access web form will automatic appear in your local database. The synchronizing of data from the web site and pulling down of the records to a local copy works automatic and without the need to write any code. In fact the sync starts automatic when you launch the client application. (it runs in disconnected mode). And any records you enter in the client application will also sync up and appear on the web site.
So, you can use Access and write zero code, and this two way sync feature is built in.
You need Access 2010, and either SharePoint 2010 (enterprise), or you can use office 365 and the $6 per month p1 plan which also does support Access web publishing.
However, I suspect issues of user logons and security may well be a greater issue here, and thus office 365 might not be correct from a user logon point of view. You can invite up to 50 users to that site for the basic $6 per month, but all users of the site will require a logon (which can be due to being invited to the site).
There are two videos of mine here showing this setup in action here:
http://www.youtube.com/playlist?list=PL27E956A1537FE1C5&feature=plcp
I think what you are trying to do is very impractical. You'll need to use Server Side Javascript to insert your data into a database, preferably SQL Server, and then you'll have to write some kind of code to sync the SQL Server Database to your Access database.
Alternately, you could setup your Access database so it connects to the same instance of SQL Server as your website using ODBC linked tables or ADO. I cannot really recommend this, especially if the data you have in your Access database is anything you wouldn't want to be public. Also, using MS Access to access a database across the WAN/Internet is really not recommended although it can certainly be done, as long as you aren't working with large amounts of data, large quantity of records, etc.
I am not willing to use any other programming language apart from Javascript.
And why aren't you willing to use something else? I don't think you're going to get anywhere if you don't open your mind to using the right tools for the right job.
Here's something that might help you get connected to SQL from Javascript:
How to connect to SQL Server database from JavaScript in the browser?
HI!
Does anyone have any idea how to synchronize MS Access data to SharePoint portal. I would like to link both of this together and trigger a workflow upon receiving a new data entry.
Hope you could advice on it.
Thanks!
In Access you can have so called "linked tables". You can have access linked tables with a Sharepoint installation. In Sharepoint this linked table manifests itself as a regular list, so you can have a workflow trigger on each new item created.
There is a nice tutorial here: How to Link SharePoint Server 2007 Lists with Microsoft Access 2007 and for Sharepoint 2010 and Acccess 2010 Microsoft hast written something nice: Synchronize a SharePoint 2010 list with Access 2010.
Additionally let me show you some Screenshots from Access. When you go to External Data > Export > Sharepoint List (see next screen)
When you click on that button you get the following dialog where you can select where to export your table to:
The same dialog you get when you Right click on a table, go to Export > Sharepoint List.
Now if you want to synchronize your data, you need to link that created Sharepoint list to your Access DB. So you click on External Data > Import > From Sharepoint List and you get the following dialog:
When you have a linked table it is synchronized with Sharepoint.
I think you are looking for this article.
http://office.microsoft.com/en-us/sharepoint-designer-help/add-a-database-as-a-data-source-HA010100908.aspx
Basically, you need to create a new Data Connection Library (pick from the Library list in the "Create" page). And then follow the steps depending on the connection method (i.e. Single Sign-On, custom connection string, or user id/password).
The process involves migrating your access tables to SharePoint. So if you moved or migrate a table in Access to SharePoint AND THEN choose to link the table, then it is a live connection to SharePoint. This is a bi-direction synnc of that table. So any change in Access (any update to that linked table) will see changes sent to the same table (list) in SharePoint. This is a VERY different process then trying to sync a whole file. So power-point files, or even a Access file does not work well at the FILE level, and you don't get any kind of multi-user setup.
However, if you migrate the tables to SharePoint lists, then any sql query you build in Access against that linked table will work just fine. And that includes append query, update query, or just a select for data.
And you can even work against these linked tables in off-line mode. This means that you can continue to update the tables even without network connection. When you do finally get wi-fi or some internet connection, then the data will auto-sync (both ways) and tables will update missing or changed data.
Note that you can even migrate and maintain related data, and SharePoint now supports relations and maintains those relations for you (referential integrity between tables is supported when using Access 2010 (or later) and SharePoint 2010 (or later).
VERY careful steps are required to migrate related tables. Access will migrate and send related tables of data to SharePoint (and maintain the relations for you). You simple have to ensure that your relations are of a type that SharePoint supports.
This means your PK has to be a autonumber ID type, and the foreign key has to be standard long data type. Since this setup is the vast majority of Access relationships, then these types of related tables move rather well to SharePoint. However, if you PK/FK setup is say a string, then such relationships don't work in SharePoint.
The other issue is to keep in mind that performance issues can arise when the row count exceeds 5000 rows when using Office 365 or hosted SharePoint. If your SharePoint system in on-premises then you can turn off some of these limits.
Migration of related data tables is easy, but you need to ensure you setup the relationships using the table lookup wizard in most cases. Sometimes you can use the relationship window, but in most cases, you need to re-build the relationship in a correct way BEFORE you migrate the tables to SharePoint. If your don't have related data, and just a few tables, then you don't really have to do much of anything in Access before you migrate such tables.
As noted, once migrated to SharePoint, then any sql query you execute against such linked tables will work fine. So no need to update the table local, or on SharePoint - the whole process is fully automatic and synced for you.
This video shows how to migrate related data tables to SharePoint if that is your requirement:
https://www.youtube.com/watch?v=3wdjYIby_b0&t=0s&list=PL27E956A1537FE1C5&index=3
Edit
Given that the tags are for SharePoint 2007, then you will find that access 2010 (or later) and SharePoint 2010 (or later) is required for referential integrity to work. And pre Access 2010, you find performance of linked lists to be rather slow, and table row counts needs to be keep small. (under 10,000 rows).
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.