Question Distributing runtime versions

[BrettM]

I have a general question for advice.

When making a custom application for distribution, what is the best way of resolving possible update issues that might arise in the source code? Should one split the application into FE and BE or is there a simple way of changing a piece of code that is found to be behaving badly (not that we EVER send out code that does that) without effecting the data?

A bit like Microsoft and their service patches. Need to fix code - not data.

Your input would be greatly appreciated.

Regards Brett

 

[Rabbie]

The simplest solution is to split the DB then you can always send out a new FE without affecting the data that is already been input. In my experience most of the changes made to a DB after release are to the FE rather than the BE and besides if the DB will have concurrent users a split is highly advisable

 

[BrettM]

so... is there any issues with using a split system and MDE format?

 

[Rabbie]

You need to keep the .mdb files as master copies so you can apply changes. If you convert the BE to a .mde then you need to link the tables from the FE .mdb before converting that to .mde

 

[BrettM]

Just to make sure I follow the steps...

Split the MDB into FE and BE.
Make COPIES.
Convert the BE to an MDE.
Re-link all the tables in the BE-MDE to the FE-MDB.
Convert the FE to an MDE.

Is is worth putting a password on the BE-MDE as well?


ps. The scales have been weighted in your favour.

 

[Dan_T4]

relinking

The two main issues I had to content with (as do most) are the re-linking of tables and managing any code references. I built tools to help me with both.

Attached is a database with a form you can almost throw into any applications to make life easier for re linking tables if you like. Its functional not sexy and if I am honest is a good few years due an overhaul.

You will need to set a reference to office is you wish to use this to use the fieldialog to find the new location.

You can on opening the application and before you open any forms with a table or query bound to it test that the tables that are supposed to be there are and if not open this form.

I have a similar form that is even more in need of an overhaul that sets the references in a runtime environment if that is an issue for you. I don't know if its good practice or not but if your application is going to live in a runtime environment, you have references set and are early binding then you can distribute the code with the references unset and then at start up prompt the user to select them. This has worked well for over 3 years unfortunately it isn't in a state to send out without long explanation that today I don't have time to give, sorry.

Let me know how you get on.

Dan

 

[Rabbie]

Just to make sure I follow the steps...

Split the MDB into FE and BE.
Make COPIES.
Convert the BE to an MDE.
Re-link all the tables in the BE-MDE to the FE-MDB.
Convert the FE to an MDE.

Is is worth putting a password on the BE-MDE as well?

That seems to be correct. You will need to repeat the last two steps if/when you update the FE database.

Putting a password on the BE-MDE is a matter of taste.

Happy you have found this useful

 

[BrettM]

Oh dear... Issues have arisen...

Just split the DB. It currently is not large at all. About 50 records with about 30 fields in each. Version is 2003. Windows is XP Pro fully patched. Office is SP2.

Prior to the split everything was displaying wonderfully. The records are loaded and checked if expired. If they are then all controls are deactivated (greyed out). Move to the next record and the check happens again. etc.

Like I said, small, fast and worked great... before the split.

Now the main screen takes about 10 seconds to display anything at initial startup and each record move takes about 3 seconds to refresh the screen. Very frustrating.

Checked the "before split copy" and it functions superbly.

The FE and the BE are both residing on a directory on my server, in the same location as the before split copy. What would splitting the DB have to do with control manipulation or with performance in general?

Regards Brett

 

[georgedwilkinson]

Put the front end on a local drive. BTW, each user of the front end should have their own copy on their local drives.

Also, not sure if it's related, if you have SP3 you need to make sure you have all the "fixes".

Let us know how that works.

 

[BrettM]

Thanks George,

Both the FE and BE have been moved to a test directory on my local system. It is a little better but still not a patch on having the lot in one MDE on the server. Still takes about 7 secs to load main screen and then about 1/4 sec for each page update. There are only about 30 controls on that page and the OnCurrent routine that I use to check the expiration looks at one control to check and then Enables/Disables and Lock/Unlocks dependant on that one control checked. Pages are Tabbed Controls but splitting should still not slow anything down.

The SP3 patch for Office has not been applied to date.

Some days I really hate computers...

 

[georgedwilkinson]

I seem to remember something about each time you first open a table, it takes longer when you use a split database. The fix for that was to create an invisible form that loads on startup that opens a dummy table. This does something like creating a linked connection that can be re-used every time you open a new table, or some such techno-babble.

I do know from my own work that the more stuff, tabs, combo boxes, etc. you have on any given form, the longer it takes when using a split db. There's just no way it could possibly be faster than a totally integrated, local solution, and is likely to be slower (but not necessarily noticeably so).

 

[georgedwilkinson]

I just thought of something else...make sure you are using indexes in the right places. Evaluate your joins and lookups to make sure, when using compound indexes, that the columns are in the right order.

 

[georgedwilkinson]

Oh, and I just remembered something else...from way back in the archives of my early VB days.

If you are manually updating the value of fields, in VB2 - VB5 at least, if you would make the field invisible, update the value, and then make the field visible, it would load the page MUCH faster. Of course, we were still using 386 machines back then and every little bit helped. I never had any flicker doing this.

 

[BrettM]

I have an update for you George.

First off, I have found that there is a small issue with tabbed controls, or possibly simply an error in the way I am coding (most probably the latter).

I am setting the accessibility and sometimes visibility of lots of controls. These controls are on 2 different tabs. I was grouping my code just based on the name of the control instead of by the tab page they are on. Change a control on page 1, then on page 2, then on page 1, then on page 2... (you get the idea) causes all sorts of display refresh issues. Even though you are not actually changing tab page views. By ordering the controls by page and then by name (looks neater too) I have fixed what looked like image breakthrough and the page refresh is running correctly.

Still wish the split system ran faster though. Main concern with not using a split system is with application updates. Do you think that keeping the application all in one and sending out a utility that runs a backup-update-restore routine would surfice? What do others in this forum do?

Regards Brett

 

[georgedwilkinson]

Application updates are EASY! Just use Bob's free FE updating tool at:
http://www.btabdevelopment.com/main/MyFreeAccessTools/tabid/78/Default.aspx

I use something very similar and it is a snap.

 

[BrettM]

I saw that a few days ago but as I'd really prefer not to split my DB I decided not to persue it. Thanks for the thought though.

Regards Brett