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.
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).
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 am doing trend analysis of data from lotus notes. I need to manually export data from lotus notes and import it into excel. Is there a way to automate this? I can even work with Access. I tried to create an agent and I do not have access to do so.
There are many ways to do this, depending on your skills and your access to the Notes database.
First of all, when you say "I do not have access to [create an agent]", are you saying that you don't have designer access to the database where the data lives?
If that is the case, simply build a separate Notes application, and write your export agent there. Put that application on the same server, and you can set the export to run every night 8or whenever you like).
Another option is to use COM in Access and pull the data over that way. You have all the COM classes documnented in the Domino Designer help, and the code should be very similar to what you would writ in Lotusscript.
A third option, if the database is web enabled, is to use HTTP to pull the data out of views. You can read it using ?ReadViewEntries, either as XML or as JSON. This requires that all the data you need is exposed in the view, though.
I think the first option is the best, though. However, if you have been tasked with creating this export, you should be able to ask for proper access to the database...
I know this is a past posting, but someone may need the latest answers get to Domino Data.
You can export any view in Notes. File -> Export -> Select CSV as the option.
Then there is the IBM ODBC driver. There are two versions. One for 8.5.3 and another for 9.x. Download here http://www.ibm.com/developerworks/lotus/toolkits.html
Instructions on how to install here http://xpagesbeast.com/uxdesign/dont-forget-about-the-notessql-driver/
Using DomSQL which is a true JDBC driver for Notes Domino data. Non Notes environments can execute SQL SELECT queries using this JDBC driver.
http://www.openntf.org/main.nsf/blog.xsp?permaLink=NHEF-8Q7AW3
Using the Domino REST Services. You can access DominoData through a URL and it returns JSON. There are URLs to get all database instances on the server, then you can get all views in the server, and you can then access documents in the views.
http://www-10.lotus.com/ldd/ddwiki.nsf/xpAPIViewer.xsp?lookupName=IBM+Domino+Access+Services+9.0.1#action=openDocument&content=catcontent&ct=api
If you cannot create an agent (no designer access) you can try to install NotesSQL (ODBC driver) besides your Notes Client and access with Excel, MsQuery, etc. with your user id.
You can find more information here: http://www.ibm.com/developerworks/lotus/products/notesdomino/notessql/
I have provided users with a view of a large data set through Sql Server Analysis Services, and they find it very easy and intuitive to manipulate.
However, I am now being asked to provide them with access to smaller and smaller data sets, for which Analysis Services is not a great fit. The reason is that they like the ease of manipulation of the data, and it's pretty flexible in it's presentation of the data.
Also, many of the data sets are available to retrieve via a REST API, in a tabular form, which I'd prefer to use rather than providing database access.
Can anyone recommend any tools or libraries (ideally open source) which:
provide an SSAS-like interface for building up a pivot table (with attributes grouped together rather than in a flat list)
can retrieve their data from a web service rather than a traditional DB?
(NB I thought about trying powerpivot, but I'm not really sure what I'd be getting myself into, so if anyone has any experience of using this I'd be interested to hear)
Powerpivot is an excel plugin for excel 2010 that uses the vertipaq engine. It has a language called DAX that is very similar to MDX,
more information can be found here
If you wish to use PowerPivot, you have three options:
1) Use PowerPivot from within Excel (it's a free add-in - be sure to install the edition that matches the edition of Excel you have, i.e. 2007 or 2010 and 32-bit or 64-bit). You are using the resources of the client machine in this configuration.
2) Use PowerPivot for SharePoint - this requires SPS 2010 Enterprise. It allows you to host (render) the PowerPivot workbook using resources from the SPS server.
3) Use SQL Server 2012 SSAS installed in Tabular mode (to build a BISM). BI Semantic Models are PowerPivot models which are hosted on a SQL Server instance. This requires a full SQL Server licence, so it's certainly not cheap. However, here you have the greatest flexibility for resources, as you can use (control/monitor) the resouces of your server.
For more information see my deck on the BISM on SlideShare.
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.