Automatically update the Shadow Database

[Peter.Greulich]

Re: Automatically update the Shadow Database

How are they getting around the "file in use" issue?

Scott,

I'm still the developer, not them. I do it like Martin -after hours or on weekends.

[Scott Kurimski]

Re: Automatically update the Shadow Database

ok, that makes sense. I develop internally and make updates during the day all the time (sometimes 3-4-5 times a day) so unfortunately I don't think that scenario would work for me. What typically happens, is someone comes in to my office and says I need this feature "now", I make the change(s), update the app, notify them, they close and reopen to get the latest version. The "downside" is that the update also affects the other clients (if they close and reopen). Generally it is not a big deal for them to wait for the update except in some of the other situations I mentioned previously in this thread. I like the idea of only updating the changed files, how are you doing that, via the date/time stamp on the files?

[Peter.Greulich]

Re: Automatically update the Shadow Database

I like the idea of only updating the changed files, how are you doing that, via the date/time stamp on the files?

Exactly.

[Scott Kurimski]

Re: Automatically update the Shadow Database

Peter, would you be willing to share your code for this so I (we) do not need to reinvent the wheel?

[Raymond Lyons]

Re: Automatically update the Shadow Database

...If the develop works directly from the network files he/she would run into trouble (I would think) because files would be in use when the app is being used by clients.
....>
How are they getting around the "file in use" issue?

In my experience, locally, on a network (server & workstations), shadowed and non-shadowed, the only files that matter for being "in use" are .DBF, .FTP and .CDX. Everything else can be copied and pasted even if the files are being "used."

In the case of shadow updates, this means, for example, that in a development environment you can make a change to a table's form, then merely copy & paste the .DDD, .DDM, and .DDX files to the shadow folder even if the user has that form open at the time. The next time they open that form, it will be the new one. The same is true for set files (except I have never tested changes to set structure, though I think that would work too). Of course you would want to do the same with the files in the Master DB if that's not where you made the changes in the first place.

This is just an FYI. Of course there may be better ways to deal with your issues.

Raymond Lyons

[martinwcole]

Re: Automatically update the Shadow Database

Peter, getting sick might be a good thing for you - I could have some of the specialists at the hospital see if they could find a cure for your sarcasm disease.

[Tom Henkel]

Re: Automatically update the Shadow Database

Scott,
Just to throw another idea into the pile. We have numerous databases running on our 200+ workstation network. They all (in some way) use related data (shared tables). Our scenario is that I create a Shadow of the database that needs to be refreshed on my machine. We then zip the shadow into a self extracting .exe file which will unzip into the appropriate shadow folder on the user's workstation along with a "tag" file showing the version number of that shadow.
We have a "Version check" text file on one of our servers which we update when we create a new shadow. That file has the database names, and a version number (usually a date). When the users start up their computers, we check the version # in the "tag" file, and if it is earlier than that in our "Version Check" file, we unzip the shadow into its appropriate folder on the local machine. If there are several, they all get done at the same time. This is part of the local machine's "Startup" process, so it doesn't really impact the workers when they attempt to get into their "real" work.

Tom

[Scott Kurimski]

Re: Automatically update the Shadow Database

Tom, cool idea, just curious do you ever release more than one update per day? If yes, how does the workstation receive the update after the initial system startup?
I am guessing when you say "Startup" you are referring to the logon process?

[Tom Henkel]

Re: Automatically update the Shadow Database

Our "Version Check" file has a layout something like this:

SocSvcs | 20110610.0
Medicaid | 20110528.0

If there is a "CRITICAL" update, we change the ".0" to ".1", and we send out a broadcast e-mail to all users that they must restart their machines. We're not talking about the logon process here, we are at the "Push the power-on button" or "Sign into Windows" point. Every Windows PC has a "Startup" process. If the routine is placed into it, the routine runs at "Startup".

Tom

[Peter.Greulich]

Re: Automatically update the Shadow Database

Peter, getting sick might be a good thing for you - I could have some of the specialists at the hospital see if they could find a cure for your sarcasm disease.

Doctor,

What happens if the system goes down while your deleting my sarcasm? It could get ugly.

[martinwcole]

Re: Automatically update the Shadow Database

the same thing that would happen if the system went down (like power failure, loss of connectivity with the server) during any refresh of the shadow using any method.

[Peter.Greulich]

Re: Automatically update the Shadow Database

the same thing that would happen if the system went down (like power failure, loss of connectivity with the server) during any refresh of the shadow using any method.

I'm just giving you a hard time. Anything programmed by Cole Custom Programming automatically gets my stamp of approval.

[martinwcole]

Re: Automatically update the Shadow Database

Most excellent answer!!!!

[DaveM]

Re: Automatically update the Shadow Database

I like the idea of building an update without alpha intrference. That was good. Never really thought of it, but had done it by hand a couple of times once I figured out what alpha was actually doing/copying.

Thanks!

[Raymond Lyons]

Re: Automatically update the Shadow Database

This is largely off topic but hey, Peter started it!

Errr...I hope I never get sick late at night in Terrell, Texas.

In an previous life I was involved in hospital quality assurance and utilization review for one the of the best trauma center hospitals in our area. I came away from that experience with 3 rules to try to follow:

Rule # 1: Unless very, very ill and there are no better alternatives, stay away from hospitals, period. Chances are they are inhabited by many who are much sicker than you, and have all kinds of bacteria, germs, and viruses, plus staff that don't wash their hands enough. Then even in the best hospitals, stuff happens, all the way from rectal thermometers being left in for hours (happened to me!) to surgeons inadvertently leaving things in you to nurses who will incompetently crank up your meds to lethal or near lethal levels to...the list could go on and on.

Rule #2: If you must be in a hospital and have any choice in the matter, avoid nights and Friday through Sunday as those times and days are very hit or miss should you need serious care and attention from the best the hospital has to offer.

Rule # 3: Push hard to be discharged before Friday (not on Friday!) or you may find yourself unnecessarily sticking around all weekend for no good reason.

Back on topic (sort of), a computer program being unavailable for a few minutes during a shadow refresh is the least of what you should worry about. Plus, as I stated above, except for table restructures, shadow files in fact can be refreshed (via copy/paste or a batch file operation) while old shadowed forms and so on are open and being used.

Possibly some of the docs on this board will disagree with my rules, but I kind of doubt it!

Raymond Lyons