I have a big Lotus Notes company database containing sensitive data and I want to prevent normal users to replicate this database locally.
Explanation of the main problems :
sensitive data on laptop
server deleted documents reappear if the purge interval is more frequent than local replications
server deleted documents reappear if users modify them locally
These solutions are NOT working in my context :
uncheck the "replicate or copy documents" in the ACL for users. If done, users cannot copy/paste content in form fields.
check "temporary disable replication" cause the application is replicated accross multiple servers
prevent local disk writing
You've ruled out all the features that are designed to help you with this, so you can't prevent local replication. All you can do is track it. There are third party products that can help you do the tracking. One of them is called SecurTrac, by a company called ExtraComm. You could write your own tracking, too, using the C API's extension manager routines, or if you don't want to write in C you could ues the Trigger Happy project on OpenNTF, which gives you some boilerplate C code that you can use to trap accesses and which allows you to call Java code to do the rest of the work of actually logging and tracking.
This does not prevent replication, but it prevents opening the database as local replica file. I have created a test database and added this code to postopen event of the database script. Just quick and dirty:
Sub Postopen(Source As Notesuidatabase)
Dim db As NotesDatabase
Dim server As String
Set db = source.Database
server = db.Server
If server = "" Then
MsgBox "you are not authorized to use this database as local replica file, it will close after click on ok button"
source.Close
Else
'opening allowed, do whatever you want
End If
End Sub
Related
I am extremely new to Ms-Access. I have a central back end access database in server computer. And all the users have the front end user interface installed on their system.
Now, whenever I make any changes to the interface in my local, i need to re-install the updated interface on each of their system. Is their any way that i can do so that i will make the changes only on my local and it will be automatically reflected on all the users' systems.
Thank you.
Ok there are a couple of options that you can do to either fully or paritally automate this process.
Partial Automation
If you don't have a lot of users and you don't want to do a great deal of coding you can write a simple batchfile or vbs file which you set up on the users desktop as an icon. Batch file code would show the following type of information.
#Echo Off
REM Copy your file from server location to local user machine
xcopy "F:\ServerDirectory\databasename.mdb" "C:\ClientDirectory\databasename.mdb" /E /Y /R
Set this up on the users machine as an icon and whenever you want them to update their front end ask them to double click the icon. This will overwrite their client with whatever you place in the location on the server. It is advisable to create all table links to the database back end having UNC paths as well.
I have used this successfully for various applications - I make changes to the front end place in appropriate location on the server and then do a quick e-mail to people just to ask them to double click the bat file icon.
Full Automation
Programmatically set version control up using visual basic so the client checks version number of the client against a server number and if the client is not the latest will download a new version.
This is more involved and full instructions are available here.
Front End Auto Update
When you deploy an MS Access solutions like this, you need to decide whether to share the client MDB file between all users, or distribute copies to each user. It sounds like you have taken the second option. Each choice has merits and disadvantages. If you stay with the current approach, you might look at a scripting option to deploy updated client MDB files between users.
Ok, our current problem is the classical "trying to allow multiple users access onto one fe file (this is in runtime currently)" - This cannot be handled (at least in AC2007) and is best solved by installing a FE on each computer that is using it.
This poses another problem for us, we have many employees who we want to be able to have access to it, yet the program probably doesn't warrent our techs to push out updates of this file to each computer with their "patches" (plus there may be added costs to doing such for us).
We would really prefer the ability for users to open a link from our internal portal to the file as can be currently achieved. We are mulling over the possibility of pushing out 4 or 5 copies of the FE application on a shared folder and creating an Access program that would essentially check to see if a FE app is open say FE1 and if so it would open FE2 (and so on) then close the sharepoint linked database that did the checking so a new user could open that. This would allow multiple users access to the same BE information using the same FE program.... would this work? Any ideas of how to go about it?
Yes it works, the idea is to create a function that checks for the open file, if it finds its open it replies with an error, on the error you can move to the following database. Here is a sample code:
Option Explicit
Function FileLocked(strFileName As String) As Boolean
On Error Resume Next
Open strFileName For Binary Access Read Write Lock Read Write As #1
Close #1
If Err.Number = 0 Then
Application.FollowHyperlink "c:\MasterMAX.accdr"
DoCmd.CloseDatabase
End If
If Err.Number <> 0 Then
Application.FollowHyperlink "c:\MasterMAX2.accdr"
End If
End Function
Disclaimer: I don't know anything about SharePoint, so I can't say if my proposed solution is still viable when SharePoint is involved.
If your problem is just how to distribute the file to all machines, why don't you let your users start a batch file that copies the Access frontend from a network share to each machine and starts it?
We are doing something similar at work (without SharePoint, though), and I described our setup here:
How to automatically update MS-Access 2007 application
We have put the batch file on a network share as well. The users have just shortcuts on their desktops to the batch file on the network share, so it's easy to update the batch file as well.
Maybe you can do something similar (let the users run the batch file from SharePoint, which copies and starts the Access frontend).
Currently we have a lot of mailfiles in different directories on the same server, some are located on the server in data\mail and others are located in data\mail\DK... or data\mail\USA...
These mailfiles are also replicated to other servers and we have noticed on the other servers the mailfiles have another file structure.
This makes administration very difficult so we would like to move all our maiLfiles to the data\mail... directories on all servers.
(Some clients have local replicas)
What is the best practise for doing this?
can the admin process do this, move the file, update person record and update clients?
AdminPs "Move to Another Server" functionality works fine for that job (watch out for the delete requests, though).
My guess is that the original administrator set up the system so that the users mailfile on the home mail server is in the root of the \mail directory and that the sub directories contain replicas of mailfiles from others servers as a means of cheap backup.
I'd suggest looking at the NAb and seeing if this is indeed the case and if it is then you are in luck. All you will need to do in this case is bring the server down, move all the mailfiles in the subdirectories into the main mail directory and restart the server. Once the server comes back up it will continue to replicate these mailfiles with the other server.
I would check the replication connection documents to see if any special replication schedules have been setup for those subdirectories, if so you'll have to adjust them to ensure proper replication.
If the users home mailserver is not using the root mail directory as their mailfile storage area then it is a longer process. You can use AdminP to do it but it COULD cause you issues if you accidently come back in at a later date and approve the deletion requests or if the server doesn't have enough diskspace to double all the mailfiles, also having two replicas of a mailfile on a single server is not a good idea either.
If you need to do the long process I'd look at doing it manually. Down the server, move the mailfiles, bring the server up and edit each person doc to set the correct location for the mailfile and then visit each user machine to edit their location document to point to correct location. It is the only safe way to do it.
The last option is to buy a new server and then use adminp to move all the users to that server, making sure the mailfiles is stored in the /mail directory, no risk of duplicate replicas on a single server, adminP looks after adjusting the settings on all the users machines and you end up with a nice clean, new server ( on which you could implement things like transaction logs and daos )
As for the safe way to go on this one:
Correcting the physical mailfile location should be quite easy (bring server down, move mailfiles, start server again), but modifying all those person documents could be quite complicated if you go one by one.
I would encourage you to use Ytria's ScanEZ software, so that you can mass-modify all person docs in the NAB using a simple Replace Substring formula to correct the Mailfile path information at once.
This is an incredibly fast process, should not take more than 10-20 seconds to go.
What I'm trying to do is seperate my existing MS Access application into a front-end (which will run locally on a user's machine) and backend (which will be hosted on a networked file server) and allow users to choose between "read-only" and "write" modes. The idea is that only one user can use the "write" mode at a time, thus preventing the same piece of inventory being allocated to mutliple customers. My problem is that the application currently handles concurrency by requiring users to open a .bat file which only allows them to enter application if a .ldb file does not already exist (there is no read-only mode currently), so I need to prevent users accessing the production data in "read-only" mode from creating a .ldb file and unessarily blocking out other users.
The biggest challenge to implemnting this is that users must have write access to the temporary tables in the MS Access (.mdb) file installed locally. I have tried to implement this using a linked table, but I'm not sure how I can control when records become locked using linked tables (which creates a .ldb file).
You could change the sharing setting back to Exclusive Mode. Then only one person can access the file at a time. Check out this link and the other sharing options you have.
http://office.microsoft.com/en-us/access-help/set-options-for-a-shared-access-database-mdb-HP005188297.aspx
Side note: Yikes. Using Access in a shared network environment is not fun. I hope nothing important/time sensitive/secure is in this file. The .ldb file not being deleted and blocking other users is something that I use to see happen regularly in this situation. I believe splitting the Access file into a front-end and back-end like you've done is the first step. Then using linked tables to a SQL Server database can help resolve these issues. But if you're going to this level of effort you may want to consider dumping Access and get a COTS product or create a new application.
Depending on which version of Access you are using, theres alot of flexibility in the UI developement. In other words, this sounds more like an "interface" issue as apposed to a "database" issue. Given everybody is able write to a table, you should be able to check in somewhat real time (performance can be an issue with larger datasets), whether a particular has been added to inventory or not.
They I handled this problem is have two tables, an incomming and outgoing log, and set up a query that did the math against the inventory list on the amount of products. And like a general ledger, select set amount of time to "close the log" (monthly, quarterly) so that the query is not taking into account stuff that happened two years ago.
If you need more help with Access related stuff, Access Monster is a good forum site that deal with nothing but access.
My problem is that the application currently handles concurrency by requiring users to open a .bat file which only allows them to enter application if a .ldb file does not already exist (there is no read-only mode currently), so I need to prevent users accessing the production data in "read-only" mode from creating a .ldb file and unessarily blocking out other users.
--> If every user has his own copy of the front-end on his own machine, you'd have to check the .ldb file of the back-end.
I guess it would be easier to give everyone write access to the backend and manage the actual writing programmatically with a "locked by User X" field in the backend:
You said:
preventing the same piece of inventory being allocated to mutliple customers
If this is the only reason for putting all users but one in read-only mode, you could put a "locked by User X" field on the inventory table. If someone starts to modify (or even opens) a piece of inventory, update the record with his user name, and delete the user name again when he's done.
If another user tries to open the same piece of inventory as well, the name of the first user will already be in the "locked by User X" field, so you can put the second user in read-only mode.
If the inventory pieces are not the only problem and all the other users really are not allowed to change anything as soon as someone else already is editing, you can create a new table with only one column and one row and use this as the "locked by User X" field. As soon as there is a user name inside, you can put everyone else in readonly mode.
No matter how you do it, you will have to provide some kind of admin menu, so if someone's front-end crashes while editing, someone else needs to be able to unlock this user's locked data (=delete his username from the "locked by User X" field).
I've got an Access 2007 database that I developed which connects to SQL Server for the actual data storage. I used the Package Solution Wizard to create a distributable installer which included access runtime (with an ACCDE file) which I went around and installed on 15 or so PCs. Anyway, my question is, what is the best way to distribute updates to this database? Right now I'd need to go around and remove and reinstall. That's not a problem... I was just wondering if there was another way.
I've tried leaving the front end on a network share but it seems that most people suggest storing the front-end on the local machine, which makes sense. The problems I've run into when I leave it on a network share (at least with Access 2003 mdbs) is that I find myself needing to compact and repair often and I also have to kill the open sessions (user's who have the file open) when upgrading. I would imagine it could also hypothetically create an unnecessary bottleneck if the user was not on the local network.
Automating front-end distribution is trivial. It's a problem that has been solved repeatedly. Tony Toews's http://autofeupdater.com is one such solution that is extremely easy to implement and completely transparent to the end user.
We developed a vbscript 'launcher' for our access apps. That is what is linked to on the start menu of user's pcs and it does the following.
It checks a version.txt file located on a network share to see whether it contains different text to a locally stored copy
If the text is different it copies the access mdb and the new version.txt to the user's hard drive.
Finally it runs the mdb in access
In order to distribute an update to the user's pc all that is required is to change the text in version.txt on the network share.
Perhaps you can implement something similar to this
Make a batch file on the server (network drive).
Create a shortcut link to that batch file.
Copy the shortcut to User's Desktop.
When user double-clicks on shortcut, it will copy a fresh copy from network to local.
Replace old database.adp on the server drive when you update a new version.
Each user gets a copy of database.adp on their machine.
Remove Security warning when opening file from network share is here.
Batch File
#ECHO OFF
REM copy from network drive to local
xcopy "Your_Network_Drive\database.adp" "C:\User\database.adp" /Y /R /F
REM call your database file - Access 2007
"C:\Program Files\Microsoft Office\Office12\MSAccess.EXE" "C:\User\database.adp"
This is a very old post and I used the autofeupdater until it stopped working so I wrote one of my own and it has evolved over the last few years into something that I have used with many clients. It's so simple to use and there is no interface. Just an EXE and a very simple config file.
Please check it out here. I can also help with custom solutions if none of the configurations work for your needs. http://www.dafran.ca/MS-Access-Front-End-Loader.aspx
After trying all of the solutions above (not exactly these solutions but these are the common suggestions in the Access community), I developed a system entirely within Access using VBA that allows an admin DB to create and publish objects to client DBs without the need for user intervention or management of multiple DB files.
This approach has several benefits:
1. It simplifies the development process by having a dedicated environment (admin DB) for development and testing totally separate from the client DBs.
2. It simplifies the update/distribution process by allowing a developer to push out updates in real time that client DBs can implement in the background, without involving users. Can also allow devs to roll back to previous versions if desired.
3. It could be used as a kind of change management system within Access for developers who want to commit multiple changes to objects and modules and retain past changes.
4. It allows for easier user access control by allowing an admin to easily assign certain objects to specific users/roles without needing to maintain multiple versions of the DB.
I will hopefully post the code to GitHub soon, I just have to get clearance from my workplace to release it. I will edit this post to include the link when I have.
We have usually kept the Access front ends on network drives, and just put up with the need to compact and repair on a regular basis. You will probably find you need to do that even when they are installed locally, anyway.
If you must have it installed locally, there are various tools which will enable you to "push out" software updates, and the guys over on ServerFault would have more information on those. Assuming such tools aren't available, the only other option I can think of is to write a small loader program that checks the local .MDB against a master copy on the server, and re-copies it across if they are different, before then launching the MDB.