Afternoon,
My company makes use of Microsofts Sharepoint facility to organize documents and such; we also use Sharepoint to hold project specific resources used by multiple people.
Question
Is it possible to access Sharepoint from within MS Access? I don't mean open it, I mean actually writing to or reading from files that are stored on it? If it's possible is there a particular module I should read up on or am required to import into any projects? (Example code or related resource would be appreciated)
Potential Use Case
Employee A makes a change to a table in a database (adding a record) which may be required by Employee B in the future. Employee B should be-able to retrieve it directly from Sharepoint without having to open a browser, download the file and manually add the table.
Thanks for any information you can give me as I know this is an odd one...
SharePoint does have MS Access integration. You can setup access to use SharePoint lists as their datasource, allowing you to edit the data from Access or from the browser.
This link provides some video tutorials on how to publish an Access web database to SharePoint. Essentially you create and edit the database in Access and you publish to SharePoint. This works well for simple databases, but it doesn't work as well for more complex databases.
Related
Looked around quite a bit before posting this - I just can't seem to get this seemingly very simple question answered (I think I missing something!)
From within MS Access 2007 I have several related tables that deal with inventory of products. I simply want to export that table data into a SharePoint List (or Lists), and link them. Users will generally just use the SP lists in order to search, view, and sometimes modify the data (i.e. mark a product as exhausted). For our work group this is preferential to opening MS Access repetitively.
The problem I'm having is that the linking features within Access don't make sense to me! I seem to be missing something fundamental here, despite reading over the MS documentation and various sources.
One can export a table, but there is no linkage between the created list and the original table. Changes made on the SP list will not be reflected in the original table which makes this a lot less useful?
One can import a list, but that linked table that is generated is NOT the original data table that I started with (the new, generated SP-linked table is a different entity than the original table. Updates to that new SP-linked table are not reflected in any original table that I had). This method seems very backwards, as you ought to have your relational DB setup correctly before attempting to make SP lists that surface that data. It seems backwards to me to make SP lists that are then wedged into an existing DB without any consideration to the existing DB structure?
So - I think that there is something fundamental that I'm missing here. It would seem that one ought to be able to just use SP to surface/provide views/editing of existing Access tables.
Isn't there just a simple way to have a SP list directly linked to an existing Access table, so that changes in the SP list are reflected in the original Access table?
I believe the solution you're looking for is the ability to "Publish" an Access DB to a SharePoint site. If you're using SharePoint 2007, the published copy will be read-only in SharePoint but users can still do everything else you described.
Details on this type of Publish are in the Office Help here:
https://support.office.com/en-us/article/Publish-a-database-to-a-SharePoint-site-8287ed04-9c65-46c4-bbdb-c965c56b018c
To quote from it:
Click the Microsoft Office Button Office button image , point to
Publish , and then click Document Management Server.
Type the URL of
the SharePoint site where you want to publish the database. If you
used the same location the last time you opened Access, the database
appears in the Publish to Web Server dialog box.
NOTE: This option is available only if your database is saved in Office Access 2007 format.
Select the library, such as a document library, where you
want to publish the database, and then click Open.
In the Name box,
type a file name for your database.
Click Publish.
If you have SharePoint 2010 or newer, users in SharePoint can have full CRUD (Create, Read, Update & Delete) capabilities to both the data and even the DB design without having to touch Access once the DB has been published. This is described in more detail here:
https://support.office.com/en-us/article/Build-and-publish-an-Access-database-to-SharePoint-e68bf007-410c-43b2-bf21-322ddbcf5411
The steps to do so are simply:
Open the Access file
Click 'Save and Publish' in the File menu
Choose 'Publish to Access Services' under the Publish heading
Specify the URL to the SharePoint site you wish to publish it to
I am building an Access Database application in MS Access 2007 which is essentially a tool for data collection which I will need to distribute to various sites to be filled out. After the sites fill out all the necessary records, they will return the tool and I will need to merge all the data from the various sites into a single database for analysis. I have 2 tables and 3 forms with a bunch of custom VBA code behind for data validation, cleaning and flow.
I have a Summary form that shows all the records currently entered. Users can then Add a record using a button on the Summary form which launches a data entry form (let's call it Data Entry Form #1). From Data Entry Form #1, there is another form that can be launched (Data Entry Form #2) for entering child records about the record being filled out on Data Entry Form #1. There is referential integrity enforced at the table level.
The flow from the Summary Form to Data Entry Form #1 and Data Entry Form #2 is important for the integrity of the data. I have dictated this flow explicitly in VBA and will instruct users to always begin at the Summary Form.
After that lengthy background, my question.....
What are my different options, and the relative advantages/disadvantages for the options for deploying this application to my various sites. My basic requirements are:
Ideally users would never see the tables in which the data is being stored in.
The Summary form would launch when opened and they could not open any other form directly.
Closing the Summary form would close the application.
Since there is a bunch of VBA code dictating important functionality, if they did not accept the Security Warning, they would not be able to access any of the forms or use the tool
I can easily script the extraction/export of the data from the two tables for each tool
I am vaguely aware of the following options:
- Distribute the full ACCDB file to the sites
- Create and distribute an AACDE file to the sites
- Use the Access Developer Extensions to "package" the application - create and EXE file?
I have also read that if users do not have Access 2007 or later, that they can download the MS Access Runtime Services and be able to use my application without having to buy/install a full version of MS Access. Can someone confirm this? Does this apply to all of the above (ACCDB, ACCDE, EXE) Is there any functionality that would not be available to them from a strictly data entry role?
Thanks!
You should be able to do most of this with options set within access, plus some code;
Create an accde;
Using that accde, in the options, untick display navigation pane (or something like that); There should be an option to disable the shift key as well.
Set startform to the summary form
Closing the summary form closes the application: In design view of the summary form (in the accdb, before you do the rest of this), create a form_unload event; In this event put
DoCmd.Quit
More of an issue might be whether or not all the sites have the necessary components of ms office to run access 2007, or if you need to provide an access 2007 runtime as well, but I'm not going there. If you need to do this, you'd best ask another question or go hunting for an existing answer.
Hope this helps
If you do want to package the database as a run-time, the MS tools are notoriously flaky when it comes to deploying. A company called SageKey sell scripts that actually work, dealing with the issue of other versions of Access being installed, and many other things.
I've used about three versions of their scripts (ie. for three different MS Access versions), and they have been great.
I've been requested to implement a means of reporting on add/update/deletes on files stored sharepoint (MOSS 2007). After a little bit of research I found out sharepoint has out of the box document auditing which I enabled a couple days ago. I ran the report today, but excel spreadsheet was not very easy to look at.
Also I'm not positive of this, but I believe only site collection administrators can generate thsi audit report, and I dont really want to give the people who want these reports that much permission.
I'm curious what are some alternatives or recommendations? Should I try and get this information off the sQL Server and display it in reporting services, or perhaps try and build a include it in a dashboard?
Thanks
If you have access to the SSRS instance for SharePoint, you can get the report file. You can then make a copy and edit for the report you would like. permissions are a separate issue that can be tackled however you desire, especially if you create a copy and store as a new report.
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).
We're looking for an easy way to display Access reports on the web. These reports have been written and viewed internally for years. They are not simple tables, but more complex charts and graphs. But, now people outside the organization need to see them. All of the data is in access. And, except for reporting everything else is working fine.
We have a web server that has permissions to see the Access database. However, the Access database server cannot be the webserver itself. So, the question is how do we view these reports on the web? This excellent solution, which I reference in case it helps others, (https://web.archive.org/web/20211020135306/https://www.4guysfromrolla.com/webtech/042600-1.shtml) does not apply, as it requires you to be on a company intranet . (Although, it may be possible to implement the solution outside of an intranet, so many security holes would be opened up that the developer leading this project would surely be fired.) If possible, we also do not want a solution that expects every client to install code, for example, the access runtime.
Is there a tool that can read the
access reports when requested? OR
Is there a tool that can upload the
data from the Access database on a
periodic basis and based on the last
retrieved data - it can display the
report that was written in access?
Other solutions ...
Thanks!
print the reports to pdf and then copy the pdf files to the webserver
Options:
output to PDF.
output to Access snapshot format and force users to use the snapshot viewer.
wait for Access 2010 with Sharepoint 2010 and Access Services and you're home free (as long as you can rewrite your reports to be full web reports, i.e., not VBA and only using the capabilities of web reports in A2010).
We deliver an Access app (and reports therefore) over a Terminal Server as a WebApp.