I am tasked with creating a version control system (of sorts) for lay people. The data is stored as arbitrary json objects but the user interface is not that low level; it is a nice pretty GUI.
Each type of versioned data will have a master copy and when a user edits the master version a copy will be created for their own workspace; a quasi local branch.
Because of the nature of our users, any conflicts that arise will need to be handled as seamlessly as possible. It can't be complicated, a git conflict-like result can't be sent to the user and expect them to learn to resolve those conflicts. Conflicts will arise because after each person has finished their work they will submit it for review and if it is accepted it will be merged into a master-like branch.
My first thoughts are to have a "meta" list of changes associated to each object, however large the nesting goes, and whenever a change occurs add that change operation to that list associated with that object. When users make workspace changes a query will check to see if other user's changes will conflict and a notification will be sent to the user for them to contact the user authoring the other portion of the conflict.
Is this a practical approach? Are there any glaring shortcomings besides being a large project? Are there better options for writing a version control system for non tech-savvy people?
You might be able to assemble something reasonable around xudiff
Related
I'm looking to use SSRS for multi-tenant reporting and I'd like the ability to have runtime-chosen Shared Data Sources for my reports. What do I mean by this? Well, I could be flexible but I think the two most likely possibilities are (however, I'm also open to other possibilities):
The Shared Data Source is dictated by the client's authentication. In my case, the "client" is a .NET application and not the user, so if this is a viable path then I'd like to somehow have the MainDB (that's what I'm calling it) Shared Data Source selected by the Service Account that the client logs in as.
Pass the name of the Shared Data Source as a parameter and let that dictate which one to use. Given that all of my clients are "trusted players", I am comfortable with this approach. While each client will have its own representative Service Account, it's just for good measure and should not be important. So instead of just calling the data source MainDB, we could instead have Client1DB and Client2DB, etc. It's okay if a new data source means a new deployment but I need this to scale easily enough as well to ~50 different data sources over time.
Why? Because we have multiple/duplicate copies of our production application for multiple customers but we don't want to duplicate everything, just the web apps and databases. We're fine with some common "back-end" things. And for SSRS, because of how expensive licenses are (and how rarely reports are ran by our users), we really want to have just a single back-end for all of our customers (I actually have a second one on standby for manual disaster recovery situations - we don't need to be too fancy here as reports are the least important DR concern we have).
I have seen this question which points to this post but I was really hoping there was a better way than this. Because of all of those additional steps/efforts/limitations/etc, I'd rather just use PowerShell to script duplicate deployments of the reports with tweaked hardcoded data sources instead of standardizing on the steps in that post. That solution feels WAY too hacky to me and doesn't seem to scale very well at all.
I've done this a bunch of terrible ways (usually hardcoded in a dynamic script), and then I discovered its actually quite simple.
Instead of using Shared Connection, use the Embedded Connection and create your Connection string based on params (or any string manipulation code)....
I'm using Microsoft Access as a means of managing data (that used to be stored in spreadsheets) in a more tabular, orderly, and logical manner. Everything seems to be working good for my client, but she has one question: "Is there a mode that allows changes to be reverted? Let's say I've made some changes, and I'd like to revert to my original version, is that possible?"
I understand her concerns and as much as I'd like to say "this is how a database works; you make changes to a row and they are written to the row immediately", I can't bring myself to say it. She's been using MS Excel and Excel has the ability of undoing multiple changes, as well as reverting back to the original file if you haven't saved it. To me, I feel that she is afraid that Access will bring about disastrous consequences--one fine day she's a bit groggy and starts making random changes all over, and then she has no means of getting back the original file. Bam.
What I'm asking now is this: is there any way/setting to allow Access to not commit changes immediately, perhaps until the user has clicked some button or something? It's not the way Access works, and please don't ask me to return to good old Excel because I enjoy and appreciate the chill WYSIWYG interface of Access and its familiar database environment. Maybe just not this behaviour, which came along with the databases.
If you are looking for a simple setting to preserve history, or enable undoing or force all changes to be encapsulated in explicit transactions, then you are out of luck as Access provides none of these out of the box.
There are however ways to implement all of these features to varying degrees, from a simple confirmation whenever the records are about to be changed, to create logs of all changes (so that the user can at least see what changed), to duplicating records before they are modified, etc.
Undoing an action can be something simple, like restoring a value you just typed, but it can become very hairy quickly if you want to undo an action that created or modified a dozen other records elsewhere in the database.
It becomes especially difficult if other actions have been performed after that one (by other users connected to the database for instance).
However, a few of things that could help you:
You can track all changes in a form and keep a log of the actions (in another table or just a text file):
Track all changes made to a record in Microsoft Access
KB197592:How to create an audit trail of record changes in a form
Creating an Audit Log
Add an Audit Trail to your database
you can use Access 2010 data macros to automatically trigger some action (like duplicating a record or keeping track of changes) whenever something is updated or added to the database.
Data Macro similar to triggers
Leveraging Data Macros in Access
you can use all forms in unbound mode and manually set the data when the form opens (or change record) and only save it back to the database when the user is completed.
All of these methods require work and testing and need to be adapted to the experience you wish to provide your user.
Another thing you can do is simply make copies of the database as backups at regular intervals, that way, if something goes awry, you haven't lost everything (this is mandatory anyway, I always have at least a daily backup system).
Backstory
I work for a company that has an online site that allows user to text personal information for collection. We collect the data, and make it available online. Users can choose to share the data with other users.
Going Forward
At some point, this may become classified an FDA-governed medical tool. In anticipation, we'd like to have in place a logging system that shows each time someone accesses our users' data, whether it be the user themselves, another authorized user, or a support person.
Current Architecture
We are currently running Ruby/Rails, and using a MySQL database. The personal information is encrypted in the database.
Data Access for Support
Today, support personnel can access data one of three ways:
admin site The admin site is limited to whatever screens we develop. While we don't currently, we could easily add logging to keep an audit trail of who accessed which data using the admin tool.
sql client I use MySQLWorkbench to access production. However, when connected this way, all personal information (user name, cell number, etc), is encrypted.
Ruby Rails console - Finally, support can log into one of the production boxes and use the Ruby/Rails console from command line. Ruby will decrypt the data, so we can do some simple things such as
u=User.find_all_by_state('active')
and it will return the recordset of all users with state='active', and decrypt their personal information in the resultset.
Holy Grail
logging
easy access for support
I'd love to be have a way to allow easy support access (once authenticated) to the data, but would log everything that is accessed (read or updated). That way, if I'm checking out my buddy's ex-wife's data for example, it gets logged to a place where I can't get in and clean it the audit trail. (See Google firing Gmail employee for an example of employees breaching the data policies).
Anyone have ideas, thoughts, experiences, suggestions with this issue?
hey devguy. This was a issue for me a couple months back. We ended up centralizing our mysql queires so that we could start to track all information coming in and out. Unfortunately the class I wrote is in PHP but the idea behind it could make it very easy to start logging.
https://code.google.com/p/php-centralized-mysql-controller/
Try stored procedures. Make all code use the stored procedures for CRUD activities. This defines an API that your developers can use while business rules are global enforced (don't return entire SSN values, but only last 4 digits, etc).
This serves as the basis for an external API as well.
If you want logging/auditing, you put it in the procedure.
This protects you from everyone except the DBAs.
David Fenton recently mentioned in another thread that
"The only proper place for any Access app (since Windows 2000, in fact) is the folder the %AppData% environment variable points to."
I greatly respect David's knowledge, especially in all matters relating to Access, but I'm confused by this statement.
What is the advantage of following this advice, especially in an environment where you are going to have multiple people using the same computer to access your app?
Won't installing to this folder only install the app for one user? And if this is true, won't installing your app multiple times leave multiple, separate copies of your app on the machine? Hard drive space is cheap these days, but I still don't want a front end file and other supporting files (graphics, Word and Excel templates, etc.) copied multiple times onto a machine when one copy will do.
What are your thoughts? Am I missing something key to understanding David's advice?
Yes, this is an issue but the only way around it is, assuming the IT admins allow it, to create a folder in the root of C drive and install the Access FE database file in that folder. That said I'd stil use the Application Data folder even if files are duplicated. As you state hard drives are cheap.
This assumes you don't mean a Terminal Server/Citrix system where users are simultaneously logged into the system.
First off, this is an issue only for a workstation that has multiple users logging on to it. That's pretty uncommon, isn't it?
Second, you admit there's no issue with disk space, so the only real issue is keeping the front end up-to-date, and that issue is really completely orthogonal to the question of where the front end is being stored.
That issue can be addressed by using any of a number of solutions that automatically copy a new version of the front end when the user opens it (if needed). Tony Toews's Auto FE Updater is the best solution I know of. It's quite versatile and easy to use, and Tony's constantly improving it.
So, in short, I don't think there's any issue here at all.
If everything is always the same for every user on a given machine, then multiple copies of a file may not be such a good idea. But when that one exception occurs, you've painted yourself into a corner. They may need a different template version for example.
You seem to be in a rare situation for an Access developer.
You're running into a bit of an issue here, because you're thinking about the environment variable name %appdata%. That variable stores the directory returned by SHGetSpecialFolderPath(CSIDL_APPDATA).
What you're looking for is the directory returned by SHGetSpecialFolderPath(CSIDL_COMMON_APPDATA). There's no environment variable for that directory. This directory is (as the name indicates) common to all users.
The advantage of David's method is that the Access data is protected by NTFS access rights, when it's in CSIDL_APPDATA. A user can only delete his copy. In CSIDL_COMMON_APPDATA, anyone can delete the single shared copy.
It's probably always best to put these advice and tips into perspective. The assumption being made here is if your application is going to be utilized in a multi user mode (that means more than one user in the application of the same time), then it's pretty much assumed that your applications going to be split into two parts. The so called application part (front end), and then the data file only part, or so called backend part.
So, you have a FE and a BE.
In this environment, each individual user within your office will have their own copy of the application placed on their workstation. The BE (data file) is thus assumed to be placed on some share folder on a server.
In the case we're not going to have multiple users running this application, or the application is not really under development, then you really don't need to split your application into two parts. However if you split your application, it means all of your users can safely work and utilize your application while you work on a copy of the next great version of this application release. Without a split environment, you really can't have any workable development cycle.
It is a long time and honored suggestion that if you're going to use access in a multi user environments, each individual user must have a copy of the front end application placed on each individual computer. If you avoid this suggestion, the end result is instability in the general operation of your application.
I have an article here that explains on a conceptual level and doesn't just tell you two split your application, but explains well why you should split your application:
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
I've been handed a rather large, old, and crusty Access 2000/2003 database to clean up. I'll need to rename a number of tables and fields, but need to do so in a way that doesn't break existing queries. (Fortunately, there are no macros, forms, or reports to worry about.)
I've heard there are some commercial tools to make this job easier, but only found one (http://www.rickworld.com/products.html).
Can anyone recommend this software, or any alternatives?
Name AutoCorrect is something I use only when I'm consciously renaming tables/fields/Access objects. When I'm done with the "great renaming" I turn it off.
For a recent project, I did that but also knocked together a little utility so I could transfer my renaming from my working database to the production database. The utility does some other things as well (such as copying relationships and deleting lookup fields). You can download it from my website's Access downloads page. It's very rough and with very little error trapping, so use at your own risk.
For the most recent project, I used Name AutoCorrect, the database above, and then Rick Fisher's Find & Replace and a very useful but no longer available Find/Replace utility called MDBSearch, credited to "Ucora and Jamie Hornstein." I don't even know where I got it, and can no longer locate it on the web. It may be available somewhere I didn't look.
I've used Black Moshannon's SpeedFerret in the past, and it's a superb product (the slickest and fullest-featured of any Access Find/Replace utility I've seen) but they've not kept up with newer versions of Access, and I see no evidence that a new version is coming out. Too bad, because at $99, it more than paid for itself within the first couple of hours of paid work.
This may be a case for Name Autocorrect: https://support.office.com/en-ie/article/Set-name-AutoCorrect-options-b475af37-dcf8-477e-a9d8-32ca9c1d4623
Name AutoCorrect is a feature that helps keep the functionality of
your database from breaking when its design is frequently changed,
especially if several users make unplanned design changes. By default,
name AutoCorrect is enabled. However, name AutoCorrect does slightly
impede system performance, and you might want to turn it off if the
database design is not subject to unplanned design changes.
Name AutoCorrect helps keep the names of database objects
synchronized. Other potential design change problems, such as problems
arising from deleted database objects, are not directly handled by
name AutoCorrect.
See also http://allenbrowne.com/bug-03.htmln Failures caused by Name AutoCorrect