0

Okay I'm looking to set up a web based service that for the most part is only used to display data to a number of users. Now initially I'd decided to make something using Sharepoint (2003) as the front end and MS Access. Now I realise that these wouldn't be anyone's first choices but here are the reasons why:

  1. Using Sharepoint makes it easy to tack on to the existing intranet.
  2. Sharepoint has good Access integration.
  3. Concurrency in Access isn't an issue as it's largely going to be read only, and only one user is ever going to be writing to it at a time.

And finally because getting IT to support anything else is a real chore. Now initially I didn't think I'd have much of an issue setting it up due to the aforementioned Access integration. However now I've looked into it I've discovered that it seems to be a one way street. You can link Access to Sharepoint Lists, but you can't link Sharepoint to an Access database. This is a problem as ideally I don't want to store the data in Sharepoint. We'll be migrating from SP2003 to 2010 sometime in the future and I want to ensure the database is preserved. Wouldn't be an issue if it was going to be purely read only, as I could keep all the data in the database and just periodically push it to the lists in Sharepoint.

However one application of the system requires the ability to write to the database. And as far as my google skills have revealed there isn't an easy way for Sharepoint to push back to the Database.

Is there a way to do what I want with the tools I have? Or would I just be better off scrapping it all and building myself something with ASP? I have done this kind of thing before but web development has never been my speciality and I'm very rusty and on a deadline. What's the path of least resistance here?

Improve this question

2 Answers 2

Reset to default
1

Forget Access and build your solution based upon SharePoint Lists. As you're running on 2003, there is no BCS/BDC solution which you can use to plug SharePoint to a database backend (but that's MS SQL, not Access).

When you're afraid about your database, you can always copy the SharePoint lists to an Access or Excel file. But there is no way you can use the SharePoint list GUI with your access backend in 2003. In 2007 and 2010, you're able to build a custom .NET connectivity assembly with the business data catalog functionality.

Improve this answer
2
  • Problem is moving forward. If I shunt too much of the implementation into Sharepoint it might get hosed when it comes to migrating to 2010. I know there are tools that could ease the process, but I'm worried this would only be a temp solution at best. Commented Jun 4, 2013 at 21:55
  • if you can create your solution using simple lists it should upgrade without any major issues. However, pain during a SharePoint upgrade is simply a fact of life and no amount of planning will take it away completely because Microsoft likes to either kill or replace core functionality from version to version. Commented Jun 4, 2013 at 22:07
0

You might want to look into saving it as a web database using Access Services. This may or may not be a good fit though and here are some specifics (good and bad). Whether it works or not depends entirely on the complexity of the Access Database.

Improve this answer
1
  • Should have made it more clear, but I'm limited to Sharepoint 2003 currently. Commented Jun 4, 2013 at 21:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.