I have a patient database which I believe should be put on server for confidentiallity reasons. Currently this database is on a stand-alone computer but now a few other Dr's want to be able to access and enter their patient data into it. I suggest that we base it on the hospital server and I use SQL but I have never touched it. I have used front-end/back-end database (Master Database and synching) but believe it isn't secure enough. Could someone tell me where I shoudl start?
Sql where do i begin
- Thread starter dfedosoff
- Start date
- Local time
- Today, 13:54
- Joined
- Aug 30, 2003
- Messages
- 36,275
That link had lots of good info but I am wondering what other options there might be out there. SharePoint 2010, saving it on a shared drive and creating backend/frontend databases. This database is not huge and will only have about 4-5 users. Is it worth it to put is on a server? Thoughts?
Creating and utilizing a split database application is not an option anytime you are going to have multiple users using your application. Whether you split it and place the back-end file on another local computer and use a simple peer-to-peer network to share the data or you place the back-end on an actual file server, or if you should decide to place the data in lists on the SharePoint site, a multi-user data should always be a split database type design (Front-end distributed to each user and the back-end file shared).
If you have access to a SharePoint site, putting your data in one or more SharePoint lists might be a good solution as it does provide some level of security because of the restrictions that can be placed on user access the site.
You did not indicate which version of Access you are using but if you are using Access 2007 or Access 2010 you can utilize the options of using SharePoint lists linked to an Access front-end. Most of my experience is with Access 2010 and SharePoint 2010. From experience I can tell you that you can have Access to export your existing tables and data to SharePoint and crate links to the new SharePoint lists. Your existing application will continue to work and will then access the data from your SharePoint site. You can also create an "accde" type file of your application and distribute that file to users. That will help prevent undesired modifications to the application itself but does nothing for the security of the data. Your uses could then use the free runtime version of Access to run your application.
There is also an option you could look at that involves using Access 2010 to create a front-end for the SharePoint lists that can be exported to the SharePoint site and users would simple access the application from the SharePoint site. It functions much as a asp.net site would. The primary thing you have to know when doing this type of development from Access is that you must use macros for any actions you need. VBA code cannot be used.
These are just some of my thoughts about your issues.
If you have access to a SharePoint site, putting your data in one or more SharePoint lists might be a good solution as it does provide some level of security because of the restrictions that can be placed on user access the site.
You did not indicate which version of Access you are using but if you are using Access 2007 or Access 2010 you can utilize the options of using SharePoint lists linked to an Access front-end. Most of my experience is with Access 2010 and SharePoint 2010. From experience I can tell you that you can have Access to export your existing tables and data to SharePoint and crate links to the new SharePoint lists. Your existing application will continue to work and will then access the data from your SharePoint site. You can also create an "accde" type file of your application and distribute that file to users. That will help prevent undesired modifications to the application itself but does nothing for the security of the data. Your uses could then use the free runtime version of Access to run your application.
There is also an option you could look at that involves using Access 2010 to create a front-end for the SharePoint lists that can be exported to the SharePoint site and users would simple access the application from the SharePoint site. It functions much as a asp.net site would. The primary thing you have to know when doing this type of development from Access is that you must use macros for any actions you need. VBA code cannot be used.
These are just some of my thoughts about your issues.
That is extremely helpful and exactly the information I needed. Yes I am running 2010 and I like the idea of using the accde option. I want to make sure no modifications are done.
If i wanted to make changes to the database does it work like the old master frontend/backend database where you have change the master back to designmaster db? I want to be able to make changes to it without too many problems.
So sharepoint has to be installed on every computerr or just on the server/harddrive where the master copy is kept?
dianaThanks in advance,
If i wanted to make changes to the database does it work like the old master frontend/backend database where you have change the master back to designmaster db? I want to be able to make changes to it without too many problems.
So sharepoint has to be installed on every computerr or just on the server/harddrive where the master copy is kept?
dianaThanks in advance,
Basically, SharePoint is a server based website. I assumed from your original post that your company might already have a SharePoint site. You will have to look into that part on your own. I am not a SharePoint guru. I know just enough about it to try to stay out of trouble.
You can modify the SharePoint lists at any point. We have made many modifications to our llsts (tables) and all that is required is that you have to refresh the link from Access to the SharePoint list.
You can modify the SharePoint lists at any point. We have made many modifications to our llsts (tables) and all that is required is that you have to refresh the link from Access to the SharePoint list.
bparkinson
Registered User.
- Local time
- Today, 14:54
- Joined
- Nov 13, 2010
- Messages
- 158
You may have a SQL Server DBA in your hospital's IT department. If so, that person could manage the SQL Server side of things, and create views and stored procedures for your app to consume. You'll get the best possible security if you go with SQL Server, too.
- Local time
- Today, 21:54
- Joined
- Sep 12, 2006
- Messages
- 16,121
surely you wouldn't be bothered about security from other doctors
i think part of the problem is your skillset. if you are comfortable developing a front end back end split in access, then that is one thing
moving to sql requires a number of things
- installing and managing sql
- upsizing the access database to sql
- being able to back up and restore the sql database - yuo can't just copy it like windows
- maybe revising quite a bit of code to work with sql, instead of access
- revising the sql app itself to use intrinsic sql facilities
you might find you need to get some professional help in to sort out the sql , if you go that way.
i think part of the problem is your skillset. if you are comfortable developing a front end back end split in access, then that is one thing
moving to sql requires a number of things
- installing and managing sql
- upsizing the access database to sql
- being able to back up and restore the sql database - yuo can't just copy it like windows
- maybe revising quite a bit of code to work with sql, instead of access
- revising the sql app itself to use intrinsic sql facilities
you might find you need to get some professional help in to sort out the sql , if you go that way.
bparkinson
Registered User.
- Local time
- Today, 14:54
- Joined
- Nov 13, 2010
- Messages
- 158
These are very valid concerns. When I started using SQL Server, I already had lots of experience with huge server based databases, and the learning curve was still steep. Took me a couple of months to get up to speed.
No SQL Server database can safely exist, be backed up, have physical design happen, stored procedures, views, triggers, etc. written without a skilled SQL Server DBA.
