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.
Related
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).
I work for a company that has an Access program that they bought the source code (the company they bought the software from no longer exist or I would contact them). I was asked modify the database to add in a couple features and add a query. I modified the source .accdb file to put in the modifications for a client since that was the only way to get the modification done and used MS Office 2010. However when I copy it to their server and try to open it in 2007 it is locked down.
Is there a reason for this and what can I do to unlock the program? I have used Google to search for this information and cannot find anything helpful to unlock the database or find out why this could be happening.
I've created a simple (asmx) web service which returns a DataSet.
I've added the webservice to my Excel 2007 workbook using the Data -> From Web button and I'm able to view / refresh the data.
The problem comes when I need to secure the web service: I've turned on Windows authentication for the web service and the request uses SSL.
Unfortunately, the user's logged on windows credentials aren't used by Excel when trying to refresh the data - the refresh fails.
If I click on Data -> Connections -> Properties -> Definition -> Edit Query, only then am I prompted for my windows credentials and does the refresh then succeed.... not a problem for me, but not something I want every user of this spreadsheet to have to do... any ideas how to make the prompt come up when the refresh is attempted instead of having it fail??
Thanks!!
Update Answers so far are to do with SharePoint and Excel Services (neither of which are any use to me)... and one link for which "The following procedure does not apply to data that is retrieved from a text file or a Web query"... I just want a person with a copy of excel on his desktop machine to be able to update from a password-protected web service... is that so hard Microsoft??
Another Update Still no answers accepted - because no answers so far have provided a working solution ( Nice googling though - thanks guys ;-) )
While I haven't got SSL I can attest that Excel normally shouldn't ask you for authentication when using pass through authentication.
My guess is that you will need to add the destination website (with the https) to your trusted zone in IE. The effect should be that when you go to the website you shouldn't be challenged for your password at all. IE will now pass through the authentication credentials because the destination is in the trusted zone.
Once this is fixed Excel should treat it like a normal website.
Here's a link which talks you through adding your site to the trusted zone: http://www.nateirwin.net/2007/01/19/enabling-ntlm-authentication-in-firefox-and-internet-explorer/
The last time I dealt with this issue was in 2004. If I remember correctly, this is a bug in the Web Query technology in how the query deals with the SSL certificate. This is Excel 97 technology; therefore, fairly basic implementation.
After much research and troubleshooting, the only way around this issue is to create user and password parameters and post the web query. Using POST will keep the user/password hidden from prying eyes.
Following is my note from 2004: There is a problem with https, application/vnd.ms-excel, Internet Query (iqy), and Excel 2000/2002.
Have you checked out this question: What do I need to do to make Excel access a Web Query via HTTPS?
Excel's Web Queries Enable You to Populate Worksheets from Web Sites at http://msdn.microsoft.com/en-us/library/aa155714(v=office.10).aspx.
Sites requiring authentication and passwords provide additional
challenges. They may require coded workarounds or may be unsolvable.
Error message when you use Web query to a secure Web page () in Excel: "Unable to open" at http://support.microsoft.com/kb/290347.
XL97: How to Create Web Query (.iqy) Files at http://support.microsoft.com/kb/157482 is an invaluable resource. (There was a Web Query SDK once that I cannot find, but this article is a good replacement.)
Different Ways of Using Web Queries in Microsoft Office Excel 2003 at .
I don't know if this will help, but I faced a similar situation while importing data from a remote SQL Server Database. What I did was create a role inside the database itself, and assign any users who needed access to that role.
The data is updated into the workbook when the file is loaded using Microsoft Query, so I don't know how that might differ from how you have done things.
The biggest issue with doing it this way was to open the properties for the query and check the "Use Trusted Connection" box. This worked without an issue for me. Again, this was from a remote server, not a secure website. Hope this helps.
i hope this will help you : Refresh connected imported data
We had a similar situation at work, however, we are using Office 2010. I'm not sure of the limitations of 2007. Check out these links. The last two are specifically for Excel 2007.
Link 1: Configure Secure Store Service for Excel Services
Link 2: Ten Tips for Using SharePoint Server 2007 with Excel Services
Link 3: Plan external data connections for Excel Services
Just curious what the experience has been in uploading MS Access tables to SharePoint 2007 list. We've been planning on doing so, but I seem to recall issues with SharePoint mangling Access tables in the resulting lists and generally the migrations not going so well. Your experiences? Best practices and recommendations? I'm particularly concerned on its ability to migrate forms and reports as well if it can do so. Thanks!
In response to a question from UK SharePoint User Group I wrote a blog post on Using Access 2007 with SharePoint lists which you might find interesting (some interesting comments too).
There is no facility to migrate forms or reports in Access 2007/SharePoint 2007, only tables. Lots of new stuff in Access 2010/SharePoint 2010 which will allow you to create Access Web databases for SharePoint.
Derek
As mentioned, the big news for Access 2010 is we can build web sites and publish applications to the web. Here is a video of me running ms-access in a browser (the 1st part is in the client, but you clearly see me switch to the browser version of the application about ½ into the video):
www.members.shaw.ca/MrTurtle/2010d1/w1.html
For access 2010 the tables (or so called lists) are going to have things like cascade deletes, cascade delete restrict. There also again a whole bunch of performance improvements that will allow much larger list sizes to perform well.
Note that the new table triggers (data macros) will also go up to SharePoint when you publish the database.
For access 2007, there is not really any particular special problems, but there is just more limitations compared to the next version of access that is coming out. So for example if you need to link up a whole bunch of related tables you have in 2007, when you push the tables up to sharepoint, you don’t have any cascade deletes or any RI options like you’ll have in access 2010.
So I don’t recommend pushing up an application with a whole bunch of interrelated tables. It just not going to work. However, if you have a simple customer list or contact list of a few thousand names that you need to share, then access 2007 should work just fine for you.
So, keep in mind if you have a list or table you need to share, then fine. However, you not going to have any luck or success if you have a whole bunch of tables that are interrelated, and you need to run the application in that fashion.
I'm trying to implement an Excel Services reporting solution in SharePoint (MOSS). Since the source data is a SharePoint list, this problem is doubly frustrating. I keep bumping up against permissions problems, even though I've enabled virtually everything in sight.
The first error is about refreshing external data - it's not (really) external data, but that's a semantic point.
The second error is a cryptic "Excel Web Access" problem.
Anyone get this to work??
Could be a couple different problems. The first possibility is that Excel Services doesn't support using SharePoint list data (crazy I know)... although this only applies if you try using the type of embedded data source you get if you choose Export to Excel from a list (again, I know crazy).
However an easy way around this problem is to use the SP webservices to get you list data. I had a macro written by someone at MS a while back that automated this conversion, if I canfind a link I'll post it. If you are using Kerberos then you task is probably finished. If using NTLM then you may need to also configure an SSO application so that the right credentials can be passed to the webservice (or any other data source for that matter). There's a pretty good step by step here.
One kind of "hack" to get this to work via UDF's (which if trusted, custom code can be deployed and made available via Excel Services) can be found here.