I just finished developing a Microsoft Access database application for a friend and he started entering data already.
He just contacted me that he would like to add additional features to the application (Nothing Major).
He is using his computer (to enter data) at one location and i use a different computer at a different location (to build the application). My Question is, is there a way when i finish updating my (empty) copy of the application to replace it with his copy of the application without effecting the data he entered into the database?
The real answer is to split the database into two: A backend with tables only, and a frontend with all forms, reports, etc.
There is a wizard that will do 99% of this for you.
When done, you can update the frontend at any time and relink the tables from the backend.
Related
I have an MS Access 2016 application that a few people use in one department. I know this whole thing has web dev written all over it but this access database has been their process for a while and there is no time right now to switch over.
Recently, a different department wants to use this application, but having their own copy. Currently, if I need to make changes, I'll make the changes in a copy of the app, they send me a current version when I'm ready to import their data, I import it and send them back a new one. However, currently I copy the data table by table and past it into the new database. This is inefficient and tedious, and now with 2 sets of data I'd be doing this for, that's crazy. There's over 20 tables so I don't want to have to manually copy over 40+ tables across the 2 apps for even the smallest change like altering a message to the user.
I know I can copy the code so I can avoid importing the data, but sometimes for big changes I'll change over 15-20 vba files.
So, a couple questions:
1.Is there a way to generate insert statements for the entire database that I could run in a script? So when I create the new copy I just upload 1 file and it populates all the data?
2.Are there any kind of dev tools that will help this process? Right now I'm thinking that it's just a downfall of creating an MS Access app, but there must be some way that people have made the "new release" process easier. My current system seems flawed and I'm looking to have a more stable process.
EDIT:
Currently I have all my data stored locally, attached to the same access file as the front end. Since I will have 2 different departments using the same functionality, how do I manage the data/the front-end? These 2 departments should have their own access file to enter data using the forms, so having 1 front end between the 2 departments won't work.
Also, should I create 2 separate back-ends? Currently I would have nothing to distinguish what is being inserted/changed/deleted from one department from the other. If I were to attach a field specifying who entered the record, that would require a complete overall of all my queries which I don't have the time for as there are deadlines I need to meet.
First thing is to split the database. There is a wizard for this.
Then you can maintain the frontend without touching the real data.
Next, consider using a script to distribute revised versions of the frontend. I once wrote an article on one proven method to handle this:
Deploy and update a Microsoft Access application in a Citrix environment
Basically I need to connect a MySql database to an IOS application and save a local copy to the device but i'm confused about which path I should take to do this.
Here is a basic description of the application:
The application is used to replace multiple paper based forms, allowing the user to complete a desired form on an iPad. Once the user has completed the form, the forms data is uploaded to a server.
Some forms have fields where the user is required to 'select' an option (drop down list). These options need to be pulled from a database because the options will be changed regularly.
The application still needs to work if there is no internet connection!
This means that whenever there is a connection the application needs to save a copy of the current database so that any required information to fill out forms is still available even if there is no connection.
In short my question is: What is my best option to save a local copy of a database (or just a few tables) to an IOS application?
You should look into Core Data. If you're trying to keep an updated copy of a couple tables, I would create a Core Data database that contains the information you need for your app and, every time the user uses your app, check to see if there's an internet connection. If there is, use NSURLSession to download the necessary data from the web server, after which you can compare the downloaded data to that which is in your Core Data database. If there are any discrepancies between the two, you can update your Core Data database as needed. This way you will always have a relatively up-to-date copy of your MySQL database.
This is a good tutorial for getting a feel for NSURLSession in case you haven't used it much.
Hope it helps!
I am starting to create an MSAccess database, I have no Access experience - my previous experience is with MySQL and Oracle. Initially I had some difficulty coming to terms with the fact that MSAccess usually stores both the front end application and the Jet Engine database in the same file. It's different from what I'm used to. Plus the database will be shared over a network, and it just makes more sense to split the application from the data.
After some reading, I see that it is possible to store data in one file, and then link to the application elements in another file. Every article I've come across for this deals with splitting the database into two parts, after the database has already been made, and never discusses creating split database applications from the start. Is it because that would be a bad idea? I can't really imagine why, except that I've noticed that Access does not let me keep two database files open at the same time (it automatically closes one). So I am foreseeing a need to constantly to open and re-open files if I go down that route.
There is one practical reason why you might want to start with a single database. If you start with a front and back end file, you'll have to create tables in one database, then set up the link for each table manually.
This is not a big deal, but if you're just starting the system, you can save some busywork by developing the pilot system in one file, then splitting it. My assumption is you'll probably be making a lot of changes to the data structure at the outset; your work will go smoother if you're working in one file.
It is definitely a good idea to split the database before you deploy it to production. I'm not sure why you're having problems opening 2 Access files at once; this is not a restriction of Access.
You can create the two db files separately at the outset. I do that often. I seldom need both open at the same time in the Access interface. I only open the back-end database, which houses the tables, indexes, and relationships, to modify the design of those db objects. And those types of changes are relatively infrequent; most of the development workload is for the front-end db. To modify data in the tables, you can use the table links from the front-end db.
It is not a bad idea. You can have two files open at the same time, either open another Access instance or launch by double-clicking the second file. Make sure you have created a suitable back-end design before you start on the front-end.
It is more efficient to have it all in one file while you're alone to work on it. Once the database design is finalised, then you can split the db.
Splitting the db is usefull during testing as well: it allows you to reset your data to a known state in about 5 sec, just by copying a saved version of the back-end.
I have a MS Access database with few tables and a form. When more than one user tried to save changes to data - I get this error:
"Configuration can't save design changes or save to a new database object because another user has file open"
Not sure why this is happening, since the design is not being changed just a data.
Any thoughts?
It is recommended to split databases in multi-user environments. This will allow you to develop on a copy of the front-end and then circulate it to the users.
http://msdn.microsoft.com/en-us/library/aa167840(office.11).aspx
I googled and it seems you have to split the database in a front-end per user and a backend containing (only) the data.
I have a website using ASP with an MS Access DB back-end for storing mainly blog posts. My company has a very long software approval process so I am stuck with what I have (i.e. I must use Access). I use server-side javascript to retrieve posts stored in the database using OLEDB calls. Everything works fine except that I cannot read any tables from the database when it is open in the MS Access program. The page displays an error message about the file being in use. This could lead to significant downtime while I am doing any work within Access. How can I make the file readable by my ASP application while it is open in Access?
Split the front end from the backend tables. Then when you open the front end it, it won't lock the database that has the database tables. This article has information on how to do this.
Make a copy for use by the web application. Make your changes in the original file, and then deploy it by overwriting the copy. You probably don't want to be making live changes in a production database, anyway. Wait until they are 100% baked.