Several years ago, I coded from scratch a complex Excel-based system for my organisation, which used an Access-compatible database as a back-end. This was in response to the broken Excel "shared spreadsheet" functionality, which would frequently crash and cause data corruption or loss.
The working system was (and still is) stored on our shared network drive.
It has now been decided that the shared network drive will be decommissioned, and all shared files will be on SharePoint. For the most part, this works well, and all other files have successfully been transferred. However I have not yet managed to find a way to make my system (Excel front end and Access back end) work with it.
When I try to run:
Dim LocalCnn As New ADODB.Connection
With LocalCnn
.Provider = CheckProvider(strPath:=DBPath)
Select Case Mode
Case "RW"
.Mode = adModeReadWrite
Case "RO"
.Mode = adModeRead
End Select
.Open ConnStr ' ERROR LINE
End With
.. then I get an error
ConnStr evaluates to:
Data Source=https://myorganisation.sharepoint.com/sites/proc2126/Shared Documents/Archive/Test.xlsmDB_ADMIN.mdb;Jet OLEDB:Database Password=mypassword
It is possibly something to do with the space in the file path? This is not something I can do anything about, as the highest directory I have access to is "Shared Documents" (with the space). The exact error message I get is:
Run-time error '-2147467259 (80004005)':
Automation error
Unspecified error
I have tried to Google the problem, connecting to a database file using VBA on SharePoint, but it seems to be inconclusive whether it's possible.
To clarify: this needs to work 100% within SharePoint, without having to download files to the local drive first.
Grateful for any advice you can provide!
NOTE: I am NOT using the MS Access program at all. This question has been tagged with ms-access because the mdb files are Access-compatible, that's all. I'm using an Excel front end, but using VBA to directly connect to the database files, bypassing the Access software entirely.
Tough luck! Access is only supported on local drives or SMB shares with leasing disabled, and previous options to run Access on SharePoint have been removed (since 2010 afaik).
You can directly migrate the data from Access to SharePoint lists (Database tools -> Move data -> SharePoint), and then use the undocumented WSS option of the ACE OLEDB provider to connect to SharePoint lists directly. See connectionstrings.com on the ACE OLEDB provider at the very bottom.
I highly recommend not doing this, and either get your organization to get a decent RDBMS that can be used as a backend (best) or get them to not fully remove the SMB share. Migrating an application to SharePoint lists will come with substantial slowdowns, limitations in what queries can run, and general misery, even though it can sort-of work (speaking from experience, unfortunately).
Related
Problem:
I'm doing this change from a .NET/MS-Access system (that I don't have the code) to a PHP/MySQL (I'm coding) one and I wanted to keep the compatibility with the old system during the trasition.
Solution attempt:
I created a linked table (ODBC conection) replacing a table in the MS-Access database keeping the same name and structure, but when using the old system to access the table it give me an "Error Establishing a Database Connection".
Additional data:
In access, when I use the option "convert to local table" in the context menu of the linked table it starts to work.
It's not necessary to be a solution using linked tables.
Using MS-Access 2013, Windows 10, MariaDB 10.4.10
Related posts:
ACCESS 2003 and MySQL - problems with linked tables
Yeah, you can't do that...
Linked tables are generally only available in Microsoft Access itself. External applications can't use them.
There's no real workaround. The easiest solution I can think of is temporarily supporting Access in your PHP application (which can be really easy or really hard depending on a lot of factors, for example, if you use Laravel there's a package for Access and it can be easy).
Alternatively, you can consider one of the databases read-only and overwrite it with information from the other on a schedule.
I plan on using Excel as the front-end and Access as the back-end only. (all queries and forms are in Excel). A single Access database will be queried from multiple Excel files that will be located on the share drive (Linux server). Access tables contain memo, text and number fields.
Data will be sent to Access tables and records will be appended/deleted; all via Excel.
There will be multiple users interacting with a single Access database via multiple Excel files located on the shared drive. Users will be interacting from different workstations with Windows 7, all have Access 2010 and Excel 2010 installed.
This process works for me from my workstation but I’m not sure what will happen when other 4 people will be sending/appending/deleting records to the same Database?
How do I make this work? What settings do I need to check in Access to make this possible?
Any advice will be greatly appreciated since I’m fairly new to Access.
Thank you!
Access is a file-server, and not a data-server.
That's means when you do a query on an Access database, all the data are going to the client part, who process the query.
Let a query "get the books written by Kernighan" in your Excel. Excel will ask to Access (throught the ADO or DAO) : "send me all the books". Access will send ALL the books, and Excel will find the book written by Kernighan.
In the same way, if Excel (still with ADO / DAO) want to make an update, it does it localy. The Access database will just set up a flag to prevent conflicts. (btw, this flag is stored in the .laccdb file)
In your case, all that are done by the ADO/DAO layer, which will
send all the data
set a flag to prevent the conflicts if one data is in Edit mode
So, to be short : yes, you can do it ;)
I am running an automated Data job on a windows server that outputs a SAS dataset everyday. On top of this, I have an Excel Report connected via Excel's Local Data Provider.
My problem is, that the Data Connection needs to be manually refreshed by a person with SAS installed on their PC. I have tried writing a piece of SAS code that opens the Excel file on the server and then triggers a piece of VBA that did the refreshing, before closing and saving. This works perfectly if I'm logged into the server. But it doesn't seem to work if nobody's signed in. I believe this has something to do with having an active user session.
UPDATE
The process that I use to connect to a local data source from Excel, looks like this:
Data Connection Wizard
Select SAS Local Data Provider from OLE DB Providers
Add the Route to my SAS Dataset as data source
Select My source table and create a Pivot Report
Is there any way to do something like this?
When you want to run Excel unattended, thus no interactive user is logged on, you can do this with a Windows service. You have to ensure some settings for Excel, as well as it is important how you start excel.
Be aware of Microsoft does not support, or even suggest you to do something like this. Excel is a client software, it is exactly the opposite of a piece of software that is easy to maintain running as as service. Read this excellent article Considerations for server-side Automation of Office about the topic. Even when a little old (talking about Office 2003) it is still state of the art.
Please consider these conditions:
You cannot use the System or Network account, you have to let the windows service running under an account that at least have excel started once. This cannot be done with the named ones (as they cannot be used as interactive users)
Excel has to be opened at least once with the user under with the windows service account will run. You'll have to configure dcom settings, open vba once to initialize it, and most probably set some settings like "trust vba model" to be able to programmatically access Excel
last but not least when starting Excel you have to start it with loading the user profile. The Process.Start method in c# allows exactly that by just setting a boolean value to true.
Doing it like this, Excel should just start fine and update data connection with the VBA.
You may want to implement that windows service in c#, as it is really easy, have a look: Creating a Basic Windows Service in C#.
When using c#, be aware of you have to correctly dispose interop objects, pretty good described in How to properly clean up Excel interop objects
In a previous question (Options for cloud based MS Access backend) one poster, Albert D. Kallal, stated:
"...you could certainly consider to up-size your Access back end tables up to office 365 and continue to use your Access front end. And more amazing is with Access 2010 this means you get a "off line" and disconnected mode. This means that your application will continue to run EVEN WITH NO internet connection. The instant you find a wifi then the data sync process starts again. And this sync is not file based, but record based and is really replication built into the product and this setup requires ZERO extra code on your part."
I am looking for any pointers as to how I may do this. I have found how to export tables into Sharepoint (but from what I can see, there is then no local copy of the tables) and have also found how to convert to a web app - but but I can't seem to find anything about how to keep my current FE, have tables in Office365, and still get the "offline" mode whereby I can still access local copies of the BE tables when I have no internet access, as posted by Albert.
Any help, or links to appropriate content, would be appreciated
Please note I am relatively advanced when it comes to Access, but am totally new to Sharepoint/Office365.
I have a spreadsheet in Excel that connects to an internal DB using the odbc driver for the software (Action Request System). That works fine. Now I'm trying to move the Excel file to a SharePoint site so that our team can review the data and make notes in the same spreadsheet.
So, first I tried just moving the Excel file to the server, but realized that the connection saved in the file was pointing to the connection file on my computer. So I moved that to the SharePoint site, and this seems to be working... Except:
1) On some of the computers, it opens just fine. But I'd prefer it if the dialog that asks for the login and pw for the DB was customized.
2) On other computers, the software and drivers are installed, but not showing up in the user source list, so it throws an error. When the user goes to create a new connection, the driver is there, (so its not in the first list, but it is in the larger list).
3) Macs can open the file, but Excel 2008 can't do the macros and connections.
4) Opening the same file from the same site throws the Trust Center warning each time, even on the same computer/same user.
Is there a way to do any of the following?
Have a non-macro that keeps the user from saving (and thus overwriting) the sheet until it is confirmed that the user won't make changes to the connections/macros?
Allow the user to connect from a local config (in case they can set one up that works when the main one fails) so that they can connect using that one but not screw it up for everyone else.
Set the trust settings (local or on server, I suppose) so that any files from a specific SharePoint are always trusted?
Finally, and this is the big one...
Can you create a connection using a driver not on the local machine? If the driver is installed on a remote server, can Excel use that one? If that were the case, that would solve almost all other problems (Unless you're on a Mac).
I feel like I'm going at this slightly wrong, but since the team all need to see each others notes, our only other solution is to upload the data (from the DB) into a MySQL db so that they can make notes from their browser. This makes it more universally available, but forces us to script a lot of functions that are standard in Excel and create redundant DBs.
Wow! Access to the ARS via ODBC! I suggested that feature to the architect when I worked at Remedy HQ back in the nineties. Great times.
Anyhow, I think your approach of sharing an Excel sheet that connects to an ODBC source is not the easiest path. (As you've been discovering.) ]
ODBC is always a local driver, afaik. A client locally connects to ODBC. ODBC then can use the network to connect to the DB.
Instead, I suggest that you investigate setting up Access with a table that is remotely connected to the ARS system. You could then remotely open the Access table via file sharing as opposed to a dbms-connection. I believe that this would be easier to get going than your current path.
HTH,
Larry
It sounds like you are using a User DSN to make the connection. You can switch to a DSN less connection by using a connection string. If you need some help with that, can you post the code that needs modified?
First, thanks to both users that provided answers. Both of you were really helpful in getting my mind around the problem.
So, it turns out that while you can't easily connect to Action Request DB directly, AR does support Web Services.
Rather than attempt to make Excel, Access, PHP, or any other system deal with creating a Soap Client and handle the work themselves, I came up with an alternative that I think is fairly clever, if I do say so myself:
1) Created a php script that calls the Web Service with the requested data,
2) The script parses the response into a more generic XML form,
3) script echoes out the xml
4) Name the script "AR_Data_Request.xml"
5) Configure the directory, via the .htaccess file, to treat xml files like php
Now, I have a static xml file which always contains the most up-to-date data from Action Request. I can point any other apps (specifically Excel) to that xml file instead of having to write VBA code to query the web service directly (and still have to do it again for php).
The only problem is that I can't get the php to connect to the Web Service (doh!) but that will be my very next question.
Thanks again!