Refresh shadow database puzzle

[brett s]

I have created a shadow database for my application on a user's local drive. It works wonderfully, superb performance too.

I created the shadow using the "Network Optimize" instructions in the A5 documentation and A5v7 Runtime - it seems to work really well. I chose the options to "refresh shadow automatically" and "entire version number" for a refresh.

The folder containing the master copy of my application (the folder containing my .ADB file etc.) sits on a shared folder on a server. The shadow is on the C: drive of the user's PC. It's a separate PC to the server of course.

I installed the shadow using a version number 0.74 of my application which I set using A5_SetAppVersionNumber(). I know I have set it correctly because I have it displayed on an "About" form in my application.

I update the application and give it a new version number of 0.75. Now I am ready to update the shadow. So I take the entire development directory (the one with the .ADB file and everything else) and copy it to the shared folder (after deleting everything there first).

Now I open up the Runtime application on the user's local drive to see what will happen. Well, nothing happens. Oh, that's not right is it?

I observe the application number has correctly updated to version 0.75 and all my application's table contents reflect the contents that I placed in the shared folder, but nothing else in the shadow has updated - e.g. forms etc are still at version 0.74.

Hmm. Something's amiss. I try forcing a shadow update using "refresh_shadow()" which I have cunningly attached to a hidden hotspot in my application in anticipation of needing it. But that does nothing. The puzzle deepens.

So I resort to opening up the control panel and using the A5 Tools menu, Refresh Shadow option. And that works! Yippeee, way to go.

But now I have a puzzle. Why did my shadow not automatically update when I ran it on the users PC after updating the shared folder to version 0.75? And why did it again not update when I ran "refresh_shadow()"? Of course I don't want my users to have to do a manual refresh shadow from the A5 control panel every time there is an update to my application.

Can anyone help me solve this one?

Many thanks.

[brett s]

OK, let me re-state my problem more succinctly.

The automatic refresh of my shadow database doesn't work, yet I am using what I would consider a routine procedure to get it to refresh - copy the new version of my application (with a new application version number) to the shared application folder then run the A5 Runtime and open the shadow database which I have previously created as per paragraph 2 in my first post above. The shadow should update automatically, but it doesn't. A5 should handle this with aplomb, but it doesn't. Why? How can I fix it?

As a possible lead, here is an observation. When I open the shadow database and before the shadow is updated, I note that the shadow's application version number (obtained via 'A5_GETappversionnumber()') is actually the new version number rather than the old. Yet the shadow hasn't yet updated (because all my objects such as forms etc, are still the old versions). So how is it that the shadow's application version number is up to date *before* the shadow has updated? The answer must come down to a question of where does A5 store the application version number?

I previously set the application version number using 'A5_SETappversionnumber()' back in my development folder and then copied everything to the shared folder.

Can anyone enlighten me please?

[csda1]

Brett,

If I understand what you did, you can't copy the application files to the shadow directory yourself. That directory is created by the network optimize (toolbar) or create_shadow() or create_shadow2() functions.

It is basically an exact copy of all data dictionaries of tables and sets in the master database, but the ADB, ALM, and ALB files are different. In addition, it creates "DBF" files that are really just pointers to the real locations of those tables. These are not regular dbf files.

Refresh_Shadow() updates a previously created shadow database while you have that shadow database open.

I have been creating a network optimization function that will do all of the hard work of dealing with network optimization, no matter what you want to do. It also can invoke A5/A5 Runtime exe patching, as well as a more robust support file copying. I'll be putting some finishing touches on it this week, but have not figured out how to make a trial version of it.

But the simplicity is as easy as saying OptimizeNet(optionNumber) and it does everything else that you need for the maintenance and operation of shadow databases. The best part is, that all users get tossed to the shadowed version (except for those you want to keep in the master version like the developer), even if they try to start the master table.

I'm not sure what the price will be, but it saves a ton of time for me!

[brett s]

Ira,

I'm absolutely and definitely *not* copying my new version's application files to the *shadow* folder, that would be a mistake - even *I* realize that. ;)

I'm copying the new version's application files to the shared folder on the server and then trying to update the shadow on a separate PC's local C: drive. As I say, this is standard stuff that A5 should be able to handle with aplomb, but doesn't.

[Peter.Greulich]

Don't feel bad. My ver. 5 application at work has worked like a charm for 10-years+. But it won't shadow in v.7.

http://msgboard.alphasoftware.com/al...ad.php?t=59669

[csda1]

To create a shadowed version, you must run the regular Master version with the Network Optimize option choice from the menu (or create_shadow() or create_shadow2()). The shadowed directory will now work. If you copy that directory to any other location (other machines, other directories etc), it will work as long as the drive mapping to the Master version is the same as the one when the shadow was created.

Also, the shadow version number, and int/whole #, and out of date settings for optimizing are stored in the ALB/ALM files. If the out of date option is set wrong on the shadow, it will never optimize automatically. Once it is refreshed manually from the master, then it will copy the Master's setting. This may be your problem.

The setting in the shadow is looked at when the shadow is opened, and operated upon at that time. If it is set wrong, it will never automatically update.

If that doesn't explain it, it sounds like you are doing the steps wrong, but I can't read your precise procedure from what you said.

[brett s]

Don't feel bad. My ver. 5 application at work has worked like a charm for 10-years+. But it won't shadow in v.7.

http://msgboard.alphasoftware.com/al...ad.php?t=59669

Peter, gee that's pretty bad. And here I am thinking that to refresh a shadow database must be one of the more frequently used and reliable parts of A5. Silly me.

[brett s]

To create a shadowed version, you must run the regular Master version with the Network Optimize option choice from the menu (or create_shadow() or create_shadow2()). The shadowed directory will now work. If you copy that directory to any other location (other machines, other directories etc), it will work as long as the drive mapping to the Master version is the same as the one when the shadow was created.

Also, the shadow version number, and int/whole #, and out of date settings for optimizing are stored in the ALB/ALM files. If the out of date option is set wrong on the shadow, it will never optimize automatically. Once it is refreshed manually from the master, then it will copy the Master's setting. This may be your problem.

The setting in the shadow is looked at when the shadow is opened, and operated upon at that time. If it is set wrong, it will never automatically update.

If that doesn't explain it, it sounds like you are doing the steps wrong, but I can't read your precise procedure from what you said.

I'm doing everything correctly and in accordance with the A5 documentation which I have read several times over a four week period, especially the bits on 'Network Optimization' and the 'set' and 'get' application version numbers.

The only thing I have doubts on is the bit you mention about the version number being stored in the in the ALB/ALM files. My new version number will be stored here along with all the other changes I have made to my scripts, forms, etc. So when I start up the A5 runtime on my shadow the first time I run it after an update to the shared folder, it should detect that there is a difference between the application number stored in the shadowed application and that in the shared, or master, application and thence update the shadow.

And this is the bit that seems to be *not* occurring correctly because when I run the Runtime shadow application the first time after the update it is telling me the version number in the shadow is the new version number *before* the shadow update has occurred. Weird.

[CALocklin]

Brett, I have been using the automatic refresh on a couple v7 apps for awhile now and have not had any problems. My first guess would be that something in an OnInit, OnActivate, or OnFetch event (or maybe one of the other events?) of the 'run on load' form is causing a problem.

Try either disabling all events in your 'run on load' form (just put an 'END' statement at the beginning of the scripts) or just disable the 'run on load' temporarily. Maybe disable the autoexec too. Maybe this may help you locate the problem.

[brett s]

Brett, I have been using the automatic refresh on a couple v7 apps for awhile now and have not had any problems. My first guess would be that something in an OnInit, OnActivate, or OnFetch event (or maybe one of the other events?) of the 'run on load' form is causing a problem.

Try either disabling all events in your 'run on load' form (just put an 'END' statement at the beginning of the scripts) or just disable the 'run on load' temporarily. Maybe disable the autoexec too. Maybe this may help you locate the problem.

Cal, I don't have any of these. I have an autoexec script that initializes a few variables and opens the main menu, that's about all though. There are no events tied to this menu either. But I can see where you are coming from. I'll dig around for few a few hours and see if I can find anything.

[brett s]

'Refresh Shadow Database' Secrets Revealed

Great, I got your attention. 8-)

Many of you will know from earlier posts of mine that I have been having problems when trying to get the A5 'refresh shadow database' feature to work with my A5 application. I wanted my shadow database to refresh automatically whenever a new master version of my A5 application was created by me and placed on the shared network folder.

The outcome is that despite all my best efforts I have been unable to get my shadow database to automatically update. I have also been unable to force it to update using the 'refresh_shadow()' Xbasic method.

The only thing saving me from total disaster is that I could always force an update from the control panel, Tools menu/ 'Refresh Shadow' option. But this is not an endearing solution as it requires me to give my application users access to the A5 control panel and it also requires me to communicate to them exactly when this refresh needs to be done. Plenty of opportunities for muck-ups here.

So I tried to find out what code behind the Tools menu option made it work when nothing else did. I was unsuccessful in this because all I discovered by looking inside the action script Xbasic code for the tools button option that it does no more than run a 'refresh_shadow()', and I already know this doesn't work.

My next step was to try and pull the 'application version number' to pieces and see how it works. This is the number A5 uses to determine what version of my application is running and thence to determine if a shadow refresh is necessary. How do I know this? Here is an extract from the A5 "Netwok Optimization" documentation:

Alpha Five allows you to set rules that automatically refresh the Shadow Database when the Master Database has been updated. You can set the version number of the master database. Then, when a user opens a shadow database that is based on an earlier version of the master database, Alpha Five can warn the user that the shadow database is out of date. Alpha Five can then automatically refresh the shadow database, or allow the user to optionally refresh the shadow database.

By way of background, there are two A5 Xbasic methods to set and get the application version number. These are, respectively: 'A5_SetAppVersionNumber()' and 'A5_GetAppVersionNumber()'. The idea is that the application developer sets the application version number when a new version of the application is ready to be distributed. And then when a shadow copy running from that new master copy is next run, A5 detects the version number has changed and either automatically updates the shadow or warns the user, depending on the option specified when the shadow database was first created. OK, got that? Except that it doesn't work.

And now the astounding bits I discovered from specific tests I conducted - these are what I previously referred to as the "secrets" now revealed:

1. The application version number that A5 recognizes is that of the master database, not the shadow.

2. 'A5_GetAppVersionNumber()' returns the master application version number, not the shadow version number.

3. There is no (or none that I have been able to find documented) A5 function or method that returns the *shadow* application version number.

To me it's very disappointing that A5 cannot handle the updating of a shadow database more elegantly. But it's now understandable in light of the above discoveries.

[csda1]

And then when a shadow copy running from that new master copy is next run, A5 detects the version number has changed and either automatically updates the shadow or warns the user, depending on the option specified when the shadow database was first created. OK, got that? Except that it doesn't work.

It does for me, and others too. We need to ascertain what's different about the methodology you are using.

1. The application version number that A5 recognizes is that of the master database, not the shadow.

Actually, it has to look at both in order to know whether it needs to update

2. 'A5_GetAppVersionNumber()' returns the master application version number, not the shadow version number.

That is correct. It returns the Master's version number whether in the Master or shadow

3. There is no (or none that I have been able to find documented) A5 function or method that returns the *shadow* application version number.

That's correct that there is no A5 function/method to do that. It is possible to get and set both, just a bit harder

To me it's very disappointing that A5 cannot handle the updating of a shadow database more elegantly. But it's now understandable in light of the above discoveries.

While Alpha is not as elegant at handling of shadowing as it could be, it does work. I do it all the time. That said, I found I could create a more elegant method to do it that allows for better handling of the process in a better way for distributed code. But Alpha's way does work.

The question is, why are you running into a brick wall here? Can you try it on a simple set of tables and test it out? Then post it, and we can test it out. Also, what is the mapping of the network drive and the shadowed drive?

[brett s]

Ira, thanks for your response. In reply. My mappings are fine. The application runs perfectly in all respects otherwise. Networked performance is very good too. I can possibly put some test samples together but that will take more time of course, whereas my priority is to complete the application. I am somewhat bemused to hear that it apparently works well for others and there is no problem? My experience is the precise opposite.

[csda1]

In reply. My mappings are fine.

What I want to know is if the Network data directory is mapped to a standard Drive, like N:, or something like \\SERVER\ALPHA

[brett s]

What I want to know is if the Network data directory is mapped to a standard Drive, like N:, or something like \\SERVER\ALPHA

The master data directory is a folder off the following shared folder on a simple peer-to-peer arrangement. (See attached gif).