We have a database with a fairly large table (300+k rows) that needs to be shared by a very small group of people (less than 5).
We previously attempted to have the table shared through Access Web Database (SharePoint 2010, so this was using SharePoint lists), but this quickly became a nightmare scenario as our morning process to load a daily inventory report into this table ran for 3+ hours using SharePoint once the inventory became significantly high. We have reverted to sharing the reports database across a network share, and the person who needs this inventory data for a different job function uses a separate front-end.
The issue we have is that when the one guy has his separate front-end open, which links to one table in the reports database, no one else can connect to the reports database; not even for read-only access.
What can be done to allow proper multi-user access? I've checked every record locking property I can think of, and still can't make anything work.
(I have to say that there are no viable alternatives to this setup. Even though we recently upgraded to SharePoint 2016 / Office 365, IT refuses to upgrade Access Web Services; so we won't have any access to SQL server, period.)
The report property sheet has a setting to lock, or not lock the table. simply change that setting, and other users can then edit data, or view the report.
Related
I have an Access 2013 database that is stored on a remote computer. I do not have it set in a back-end/front-end setup. I have a SharePoint 2010 list linked to it as a linked table. I have 2 users that need to have access to the database at all times, others may need in it at a later date. When I link the table, only 1 user can be in the database at a time. Prior to adding the linked table, all users were able to use the database simultaneously. Now, after the first person gets into the database, subsequent users get the message:
The database has been placed in a state by user 'Admin' on machine '[computername]' that prevents it from being opened or locked.
For testing purposes, I tried creating a blank database that is connecting to that same table and tried to open it from another computer. I received the same error and all that is in there are the 3 tables needed for the SharePoint list.
Is there anything I can do to be able to have multiple users in my database again? I have full control to make changes as needed to the database, but I have no access to be able to change anything server side on SharePoint.
This is because of the 2010 SharePoint caching format.
You can avoid this behavior by going to Options -> Current database -> Caching Web Service and SharePoint tables, and untick Use the cache format that's compatible with Access 2010 or later.
Note that the different cache formats come with different features. The old (XML-based) cache format supports multiple users, the new (table-based) one doesn't. The old cache format can be taken offline manually and needs to be synchronized manually if offline, the new one automatically goes offline if SharePoint is unavailable and synchronizes automatically as soon as SharePoint becomes available. The new one supports adding fields in table view, the old one doesn't.
Through VBA you can mix caching formats for different lists, but that's generally not recommended.
Using Access 2013, Sharepoint 2010 OnPremise
I have an Access database that uses Sharepoint 2010 for a back end using Linked Tables.
A few months ago there was a request to have a field contain multiple values, and I stupidly implemented that change, not fully understanding all the issues behind that. Initial research lead to it being "ok" for Sharepoint Lists.
Due to the company architecture, this application needs to be accessible on a Kiosk machine that doesn't have access to the Sharepoint site, but still is connected to the internet.
If the computer runs the application while connected to the internet it will hangup/stall when opening because it's trying to resolve the connection of the linked tables or trying authenticate.
But if the computer runs the application while not connected to the internet it will operate as it should in an offline mode. All data is accessible.
Since we can't/don't want to disable the internet of the Kiosk machine the solution was to convert all the Linked Tables to local tables and issue it to the machine that way.
But now a few months later when trying to make the offline mode application we get the following error:
You cannot enter that value because it duplicates an existing value in the multi-valued lookup or attachment field
I think it has to do with that multivalue field, which has turned into a huge headache, but can't be undone for at least a couple more months.
The Offline mode functionality was created long before the multivalue change, unfortunately that part of the application wasn't tested against this changed field.
So I need to know if there's a way I can convert the table, or if there's another way to Force Access 2013 into an offline mode.
Thanks,
Dennis
I am using MS Access 10 in a multi-user environment. The DB is split with tables in the back end (stored on a network drive), and everything else in the front-end (stored on about five different computers).
Some of the front-end computers are using Access 07, but the DBs were created in the 07 format. I have checked that the database is NOT using the 2010 encryption, and all the other 10 settings that are not compatible with 07. In fact, the 07 computers will run the DB just fine when alone... the problem is when more than one person logs into the DB.
Often there is a "Too Many Active Users" error when trying to sign in. Other times, users are able to log-in and open forms, but whenever changes are made we get "locked" errors. (This happens on all computers, not just the ones running 07).
All the DB copies have record-level locking, but it behaves as if it is locking the entire table. I have checked, and none open the DB in "exclusive" mode. (When you go to the navigation pane, and open the table, the table itself will not allow new entries).
I have tried creating the forms based on queries and also with filters instead. I get the same locking problems either way (Does anyone know if queries or filters lock data differently?).
This is forcing the DB to be used by one user at a time, when multiple people need access. Is there anything I am overlooking? All have permissions set to the network drive, I removed the "compact on close", I tried converting to an ACCDE file (the ACCDE file will not open in 07, only 10, but we get the same locking errors).
Can anyone think of what I might be missing here?
I have an access database/forms, controlled by VBA. Records can be deleted/modified and added. What is the best/natural way to share this database within only 3 desktop PCs? Would network share from one of the PCs would be sufficient and automatically taken care by MS Access? What additional actions in VBA I have to take care of? I'm mostly using CurrentDb.Execute to add/update and delete.
Split the data and application into separate databases
Compile the application potion into an .mde (or equiv in 2007) to keep your users from messing with it, and put it on a share (or you can distribute it to each machine if you need performance).
Put the data db on a network share.
Ob. MS SQL Plug- better yet, convert the data db from MS Access into MS-SQL, and host it on a server and save your self some future pain, because with multiple users, MS Access is known to corrupt its own database from time to time. Even 2007.
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).