I have an MS Access database which is already linked with many tables in Oracle.
I want to add few more tables to that from different server of Oracle.
The problem is if I connect to the server through MS Access and try to import using linked table manager I could not find my schema or user in that list of tables.
This Link tables dialog even from Get External data->Link Tables gives me only system tables like (CTXSYS,DMSYS,XDB etc....).
Why can I not find any of my tables? Do I not have access to this?
How do I achieve this? Why are my table schema's not listed even if I connect to the right server?
I don't recall how the Linked Table Manager worked in Access 2000, so I may be off base here. However, in Access 2003, the Linked Table Manager allows me to change the connections for existing table links, but doesn't provide an option to create new links. (at least not an option I can find)
IOW, if the same source table existed on a different server, I could use the Linked Table Manager to change an existing link for that table to point to the new server. But, with no existing link to the source table, I can't use the Linked Table Manager to create one.
For that purpose, I go to Access' main menu and choose File -> Get External Data -> Link Tables, choose "ODBC Databases()" from the "Files of Type" box on the Link dialog, then choose the DSN for the server which houses the tables I want linked. IIRC, you should have a similar option with Access 2000.
You could also use VBA code to create your links. See TransferDatabase Method.
Related
I have Views on a SQL server database that I have painstakingly written. I am creating linked tables on my MS Access Database. I am only able to pick from tables. Is there a way to use my Views on the SQL Server within MS Access, which has all the data I need?
Views in SSMS:
Can only see Tables in MS Access linked Tables manager:
Yes, you can. From Access' point of view, linked tables and views are almost identical.
Except when linking a view, you need to tell Access the primary key - for tables it it determined automatically. Without specifying the PK, the linked view is read-only.
The Linked Tables Manager in Access shows only tables/views that are already linked.
To automate the process, see here: https://stackoverflow.com/a/32316883/3820271
I inherited an Access database where the (local) tables seem to be all grayed out, at least the existing ones. They only show up when I check "Show system objects" but many of these are not system tables. How can I "un-system" them? When right-clicking and going to Properties, it shows as hidden with the check box disabled. And yet if I turn off "show hidden objects" they're still there.
EDIT: Just to clarify, user defined tables are showing up as system tables and are "hidden" and I'm unable to uncheck the hidden box. This is a COPY of the backend of a split database, on my local hard drive and no one else has it open.
This would suggest that the database is being opened as read only.
It is also possible that you are using a older version of Access, and the database and tables in question have used "newer" features. In Access 2010, they introduced table macros. This feature allows you to attach triggers and stored procedure code to tables. However, if you open a 2010 database that used these features with say 2007, then everything will be set as read only. So, this is either some file permissions are attached to this file, or you are opening the accDB file with a "older" or "previous" version of access that does not support the features used in those table(s).
I would create a new blank database, and then import all of the tables etc. into that newer database. That should give you update rights.
I'm using MS ACCESS 2000.
I have few tables in AB.mdb linked to some other table XY.mdb in my machine. Its working fine in my machine local.
Now if i move this AB.mdb to some other machine its showing error as its is searching for XY.mdb in its local machine.
I cannot change path in that machine using linked table manager because we dont have access from that machine.
Is there any way to solve this issue.
any way to change path of linked tabels other than linked table manager
Thanks,
Shanmugam
You can change the linked tables target programmatically in VBA.
Access: Changing linked table location programatically
Reconnect Attached tables on Start-up
Relink tables in code
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.