I've been researching this question over the last few days as I prepare to deliver the first of 3 phases with my first system using a split database. I would like your advice as I haven't found enough info to make a full decision yet.
At the moment I'm working in dev on an unsplit database. When I split it in live I'll take a copy of both parts but what do I do with them for phase 2?
I'm thinking that I'll now make them my dev version after relinking the tables (as I've effectively moved the back end) which would then mean that I no longer work with the unsplit database. Is that the right approach?
When it comes to putting phase 2 live I don't think I have any choice other than manually applying table updates to the live back end (once backed up). For the live front end, do I just replace it with my dev front end and then relink the tables or do I export the changes into the live front end? I guess I could do either depending on the number of objects that are changing/new. Is that right? I'll then take copies and make them my dev versions for phase 3.
Finally in dev I have form and report templates and test forms, reports and queries which are not needed in live so do I remove them for each deployment and then add them all back in to the new dev front end or just put them live? Normally I would take them out but there are a lot of them and I don't know of any quick way to add them back in so what do you do?
Primarily my questions are asked from a risk point of view - what steps best reduce the risk of messing things up in live.
Update:
For those of you who are looking for answers on this, in addition to the fine responses below I have since found the following that might also help:
How to Continuously Develop and Deploy an Access 2010 Database Application
At the moment I'm working in dev on an unsplit database. W
Don't, a VERY bad idea. How this works?
Well, for sure at the start, you are building LOTS of new tables, changing relationships, and building tables at a high rate of development.
so, at this point in time, you can develop un-split.
You will then find after some time the rate (and need) to create new tables, and change the so called "database schema" calms down to a dull roar.
At this point your still developing away - not yet deployed.
So, somewhere around this point? You want to split. You REALLY want to do this.
There is a boatload of reasons for this, but several are:
while a split vs non split is "very similar", they are not the same!
Thus, you can't and don't want to develop code that NOT really tested
as to HOW the code will run in the real world
So, many issues can change or crop up during development that is DIFFERENT when run split. So some commands (such as seek()) don't work, and a few other issues can crop up. You don't want to develop for a whole week, then split and now find 20 hard to fix bugs in your code. So, by developing as split as soon as possible, then ANY and ALL issues that come up will be seen as you develop along, and thus can fix, see, and deal with such issues at THAT POINT in time. Much worse is to write a bunch of code, get ready to deploy, and then find new bugs.
Next up:
Having a split system is great, since say a customer might let you remote into their system. You can pull down a copy of their data, re-link your tables to point from your "test data" to real live production data.
Or, say your developing on site. You might want to test some dangerous delete code, or code that modifies the data. So, you can't risk working on production data, so now you re-link and point to your test back end. So, this setup allows you to test code, but MORE important test on a copy of the database with great ease.
And it also allows you to develop off site. You can take the latest front end for their system, maybe get their latest data file, maybe not. but you can now with ease simple change the database that your applcation runs with.
The other big issue? Say your working on site, and have a test database of theirs on the network folder. You write some code, test for a new report. You find it runs SLOW AS A TURTLE. You check your code, maybe add a few indexes, and boom! - your report now runs great.
If you test un-split, then a boatload of performance issues can crop up, but NOT SEEN during the development cycle. Once again, you don't want to develop for weeks or whatever, split, and NOW find a whole bunch of forms and code runs REALLY slow.
So, the goal, the idea here?
You want to get split as SOON as possible?
How soon?
Well, this is one of those things that only you can know!!!
As I stated, at start of development, sure, start out un-split.
Once the table designs are quite solid, then you can split. You then ALWAYS develop as split (and the above list of reasons why is the VERY short list - there are many more reasons).
Now, the problem of course with split? Say you want to add a new column to a table?
Well, it is MORE work, since now ANY AND ALL changes to the data schema are done in the back end. So, you have to close down the front end (FE), open the back end, and now use the table designer to add that one column. (or maybe change or setup a new relationship between some tables. Or maybe add a new table).
This is a "bit more" work, since now you close down the BE, and open the FE, and now you MUST re-link tables. And if you added new tables to the BE, then you have to add that/those new table links.
Because this "dance" is extra work, that is why you wait as long as possible to split. As I stated, you "just know" when that time has arrived to split. (when table and schema tables changes settles down to a low rate of change). Since the rate of change is now low in regards to table changes, then it not much work nor pain to have to do the above every time you want to change the table structures.
In fact, think of any program you buy? It has a applcation part, and then a data file part. In effect, once you split, you have the same two parts, and in fact in some applications I written, they are allowed to use "different" back ends - not unlike any other applcation in which you launch the applcation, and THEN choose the datafile to work with.
So, what about developing off site? Well, that can be REALLY difficult, since you have your own copy of the FE and the BE.
If you HAVE TO make changes to the BE?
I open up a work document. And if I add a new column to say tblCusotmers?
Then I enter this:
Add new column TaxRate, Currency, to table tblCustomers
So, you build up a "log" of changes. Now, when you travel to the customer site, and want to roll out and deploy the new FE? Well, you have to FIRST open up their BE, and make the above changes to their production BE database.
Now in some cases, where is was not possible for me to be on site? (in fact, I had a automatic update system to automatic roll out a new version of my software - and it would automatic down load from the internet. In this case? I had to write code in the FE on startup that would use VBA code to MAKE the changes to the data tables. This can be REALLY hard to do, but is possible. I just recommend the plane jane word document, and you keep track of your changes.
So, the above is quite much how this development process works.
Since you will have to re-link the tables? Then near everyone has googled for a VBA table re-link routines. You want that, since having such code is MUCH easier then say using the linked table manager each time. And we even often have a table in the FE that saves the BE server location, and on startup will check, and if the location of the files don't match, we launch the re-link code.
that way, you can deploy the applcation to different sites, and have it automatic re-link. Another way is to have a simple text file in the same location as the FE on each computer, and on startup read the text file with the BE location - and re-link if required.
So, the typical process to role out a new FE (which is placed on each work station - do NOT break this rule!!!).
So, I point/relink my front end to the production BE. I then compile down to a accDE, and then deploy that new compiled FE to all the work stations. In fact, I have some code in VBA at start up that compares a version number, and if the version number is lower, then the VBA code will copy down the next FE sitting in a folder.
This might not be a big deal if you have 2-4 users. But, if you have two sites, and each has 35 users, then you want to figure out a automated approach.
However, do not prolong jumping over to the split development cycle, as you really for all practical purposes MUST develop in a split environment. So, for the first part, you can develop un-split. But, once you split - that's it, and from that point on-wards, you are to develop as split. There are boatloads of benefits, but it also really quite much standard approach from a developer point of view.
So, you have to master the linked table manager rite quick, and then VERY much consider adding some re-link code, since you want with great ease to point to a different back end - including at deployment time.
so, as a general rule, you should think of your FE like a .exe program, for a new version roll out, yes, you copy (over write) their existing FE's on each work station. And as noted, in most cases, it should be a compiled accDE, and not a un-compiled accDB for the FE.
For reducing risk:
you should have your development version, a test version for live and the live version.
You are developing on develop
Customer tests the changes on test (with test data)
after that you move to live
For the move from develop to test I create an update/migration script.
In this script are all alterations included that needs to be done on the back-end.
I use the script to create the test version and with this I can check if it is working properly.
In case there are database changes that I can't reflect in my script (either insufficient skill or restrictions from db) I add them to my checklist.
I am using version control to see changes during development and to import modules, queries etc. to the new version.
Updating the front end is done via Import of the latest version (without not needed forms / reports).
I am building an application that connects to a mysql database. I set up the data connections and data source (data set) and have begun working on development, going back and forth between adding tables and views to the database and adding forms and components to the application.
I have up to now used the "Configure Data Source with Wizard" wizard to refresh the dataset in the application. Sometimes it takes a couple click throughs to get it to fully load the changes, but that's not the end of the world.
Today, without me knowingly changing anything, when I click on the wizard button, the frame of the wizard opens and closes instantly.
My data is accessible, and the parts of the application already developed work just fine, but I don't know how to add new tables and views to my project. My worry is that something went screwy in one of the auto generated dbDataSet.* files.
I'm happy to provide more information if that will help.
To answer my own question for whomever comes here next:
I came across this solution:
https://stackoverflow.com/a/4749044/7640114
It links to a microsoft.com page that is no longer available, but copies the relevant information. Finding the corresponding files is not hard, but knowing what the wrong Provider is may not be so simple.
Mostly because of a lack of patience, I just went with the second option and deleted the entire folder, which may have been overkill. It worked, and I have access to the wizard again and can continue development, but it also wiped out my workspace layout which I now have to rebuild from my memory.
Win some/loose some. In the end, I suggest being more delicate and removing lines of code from DefaultView.SEView first, and then moving on to trying to delete the file and the folder if nessasary.
I know the "merge tables" question has already been asked in a variety of ways, but I can't seem to find an answer to my specific question.
Here's my deal: I've been designing a WordPress site for an organization for four weeks. When I began designing I took an export of the database and imported into my local development site. In the meantime, this organization has naturally continued to post things and receive/approve comments on their live site. On the local side, I have also created posts, edited pages, changed widgets, etc during development. So now that we're ready to launch the new site, I need to figure out how to merge these last four weeks of database changes from both the live site and the local site without losing anything on either side. How is this done?
If there have been inserts to both databases, then unfortunately there isn't a good way to merge. If your database contains the latest edits for the Post IDs that are shared then you can export them to XML and then import them into the other site.
This is done with the WordPress Importer plugin which can also be installed by visiting /wp-admin/import.php, the export can be done on /wp-admin/export.php. You can also remove any conflicts from the XML file manually, but make sure that you keep it well-formed.
Currently I'm working with an in house white label cms that we resell to multiple clients and it all runs from the same box/db.
I'm just looking at converting this to have an ecommerce version that we'll run alongside it.
I'm wondering whether there will be an issue keeping all the products/categories/orders in one db or whether it would be advisory to separate each instance of the site into its own db for this.
These white label instances will only be sold to smaller companies that probably wont have masses of traffic/products and are looking for a simple ecommerce site. Anything larger will definitely get its own hosting and db.
But for smaller scale stuff do you think a single db will be ok?
#Tim: Aye I agree completely, however as I'm working from an existing codebase all of the site specific filtering code is built in. All I need to do is add a couple of fields to each table and the backend will already take care of all that filter for me.
Also the codebase I'm working from is set up with multiple access levels, user(public), userAdmin(customer) and admin(me), and is built in suck a way that I can generate a new site from the admin portal. I then just need to upload new templates/css/js/images and the whole new site is created.
So theoretically it may be more work to have to separate out the ecommerce databases than it would be to leave it in one.
Hence the question, if there is likely to be issues with having multiple sites in one DB I'll split it out, but if it's not going to make too much odds I'll leave it as is...
In fact I think I just answered my own question, I'll implement it into the existing codebase and set it up to run on one db, with the knowledge that i can always install the whole codebase on another box and run a single site on it if I need to :)
Thanks for the quick reply
Having everything piled into a single DB is going to complicate your code considerably. Instead of it being a configuration difference (which DB to connect to), you're going to be peppering your code with filters based on the current customer. I would vote for separate DBs in a heartbeat. Even if you wind up with excessive load from all the small DBs, it should be easy to add a new DB server and point new sites to the DB on the new server.
I can't see the complications this would create in your code being worth it in the long run.
I'm using wordpress as a simple backend CMS for a flash site. Posts are queried and displayed in list format on the frontend. I want to be able to make post edits or add new posts on my staging server, and have a quick and easy way to publish changes to production without having to do a full mysql db dump / import. I've looked around for plugins or solutions but haven't found any. Seems like wordpress needs a "publish to production" option.
The intended workflow is that users can create or edit content as much as they want, then an editor will go through it and approve content. Once everything looks good on staging, we publish to production. Any ideas?
Some of this thread at Wordpress might be relevant for you as it concerns moving from staging to production and the use of relative and absolute paths, etc.
WordPress does have a preview button that should allow you to see the WP content without actually publishing. If you must see it in the flash site, I think your best bet will be to setup your flash site with XML-PRC.