Updating Alpha with open sessions

[Jeff Fried]

It's not clear to me what updates can be performed while a user has the application open. For example, if at least one user is working in an order entry form that I modified, then I copy the .se? files in, is it an acceptable practice? I.e., will it simply take effect for anyone in the application the next time they go out and come in? Or are there dire circumstances surrounding this practice?

If this turns out to be a "there are certain things you can do, and others you can't" thing, I wonder if there's any place where this is written up.

Thank you if you're knowledgeable about this topic.

Jeff

[forskare]

RE: Updating Alpha with open sessions

When you update your app, no one else should have the app open. All users should be off. Not sure if that's a hard and fast rule but if I were updating an app, I'd make sure everyone was off. You also must do the network optimize from each computer.

kenn

[Jeff Fried]

RE: Updating Alpha with open sessions

Ken,

I know that that's the standard protocol, i.e., everyone should be out. But I'm more after knowing where there are risks and what the effect is when someone is open. Sometimes I have changes to make that don't warrant having everyone exit A5. Other times, I might access a network at night and determine that at least one person left the app open, and wonder whether I can copy in the files.

Jeff

[forskare]

RE: Updating Alpha with open sessions

Perhaps you should consider establishing some 'Rules of the Road', such as.....No updating unless ALL users are out.

Since Alpha says to do an update when everyone is out, that implies to me that there could be problems if someone is still open. For me, I would not do an update unless everyone is out. However, if you want to find out what happens, give it a try AFTER you back up the app.

kenn

[Jerry Gray]

RE: Updating Alpha with open sessions

Jeff,

For what it's worth, Dr. Peter Wayne's book Application Programming in AlphaFive Version 5 has a routine to force users off the network. It's on page 278.

Jerry Gray

[CALocklin]

RE: Updating Alpha with open sessions

I've installed new data dictionary files a number of times while the current user was working in the app and, so far, have never had a problem. (I always install them in groups - i.e., never just the .ddd file but the three matching .ddd, .ddm, and .ddx files.)

However, I don't recommend this for beginners or casual users. There are a number of issues to be considered. Here are the ones I can think of off the top of my head:
- which files are copied. (as noted above)
- effects of shadowed workstations. (there are a few implications here which you should be able to figure out if you are familiar with how shadowing works)
- never do it if table restructuring is involved.
- new scripts that may cause restructuring should be avoided. (ref: a5_add_fields_to_table() and others)

I have used this method mostly to test new forms, scripts, etc. on one system before implementing something as a full-blown update for all users.

And, as Ken pointed out, backups are always a good thing.

Cal Locklin
www.aimsdc.net

[Jeff Fried]

RE: Updating Alpha with open sessions

Jerry,

That's a refreshing idea. I'll check it out. I have one client -- and only one who does this -- who has employees who refuse to exit when they leave work. They've been told, but either they (1 or 2 of them) are brain dead or hopelessly defiant. If it were my company, I would fire them because they're putting the company's critical data at risk (can't back up the open files during overnight backup routine).

Jeff

[Jeff Fried]

RE: Updating Alpha with open sessions

Cal,

That's the kind of info I was looking for. Regarding restructuring, I would never attempt anything like that if anyone was open, anyhow. That aside, I was thinking more in terms of a form or rules change, and yes, I copy over the whole family of dd's for that form. When I only change a few things, I do a simple dir /od in the data directory (in DOS), which shows me the latest things that changed. The families of dd's are always grouped together anyhow (date/time changes are the same) and well as the se's and al's. I'm also trying to understand the effects of doing these changes while someone is in. For example, if I change field rules while someone is in the affected table, I assume the rule change will not apply to them until they go out and come back in. But anyone not in who goes in after I copy the rule change over will now have the new rules in effect, right? And, more importantly, under this scenario, I have not done anything to risk the data or to distort the changes I have made, right? I'm looking for confirmation of this since sometimes want to put a change on the system during working hours without having disruptions to employee work flows.

Thanks.

Jeff

[CALocklin]

RE: Updating Alpha with open sessions

Those are good questions and I would assume the same things as you. However, I haven't specifically tested them.

Be careful - sorting by date doesn't necessarily keep data dictionaries together. Sometimes during development the dates do change on one file and not the other.

I don't recall ever doing this to change field rules so I'm not sure what the results would be.

Also remember that it will only affect the workstations that you add the new files to unless you put them on the server and force the workstations to update.

Something else I've done is to update the server with the new data dictionaries so the workstations will be updated the next time they start. (Obviously with an updated network opt number.) When I do this, the .al* files are the last ones to be added. This way someone who happens to log in while I'm adding the files won't be forced into an update until all the files are ready.

Cal Locklin
www.aimsdc.net

[Jeff Fried]

RE: Updating Alpha with open sessions

Cal,

I forgot to mention that these are situations where the workstations are not shadowed yet, so I'm updating the one server location only. My assumption is that once I implement shadowing, I'll make that happen automatically anyhow.

I'm disturbed that there are files that don't update the date and time attributes when changes are made to them. Now I'm beginning to wonder if the .alx file does not update its date and time while its relatives, .alb, .alm., and .adb, are updated. I would sometimes exclude .alx, thinking that it hasn't been touched. If what you're saying is true, this would appear to be a serious flaw in Alpha. I hope somebody from development picks up on this and fixes it. I will in the future be vigilante and include the whole family (less .dbf, .cdx, and .fpt) when I copy over the updates.

Thanks.

Jeff

[CALocklin]

RE: Updating Alpha with open sessions

I could be wrong but I believe the date does change if the file is modified. However, it's entirely possible that, for example, the .ddd file might change without changing the .ddm or .ddx file. (That's like saying you have corrected someone's phone number but did not change the memo for that record and did not affect the indexes because there is no index on phone.) I suppose you could just copy the file(s) with newer dates but then you would have to compare the 'new' files with the 'existing' files because it's probably possible that something like the following could happen....

1. All files updated on 1/1/2005 for development and production app.
2. .ddx file in development version updated on 1/2/2005.
3. .ddd and .ddm file in development version updated on 1/7/2005.

Now, if you updated only the latest files, that would be only the .ddd and .ddm file but the .ddx file would also be new since the production app was released.

Therefore, the safest method is to always update all three matching dictionary files.