Optimized Network

[Thomas Henkel]

Being very new to ver 4, I am curious about this network optimized stuff.

We have over 250 users on a network sharing databases and applications in ver 1.02. If we use network optimization, does that mean that ALL of our users will have copies of our tables on their machines?? There are over 1000 active tables in our application.

Maybe I just don't get it, but for each user to have copies of the database tables would seem very un-optimized.

I am not criticizing, just trying to understand.

[BRochford]

When you Network Optimize each user is still using the Data held on the Server, but they each have their own copies of all forms, reports etc. Thus saving mucho time by not having to send the forms etc over the Network. The actual data (.dbf, cdx, fpt's) is represented as a "shadow" which points to the server plus all other Alpha files such as adb, alm alx, ddd, ddm ddx and the set, sem, sex files are copied onto each users hard drive.

From the A5 control panel, click help "Network" you will be able to read all about Network Optimization.

-Barry

[Peter.Greulich]

Thomas,
Optimization is kind of hard to understand until you really check it out. It is definitely the way to go. Even very fast machines tend to drag over the network. With optimization, Alpha flys!

[Thomas Henkel]

THIS IS ALL WELL AND GOOD, BUT WHAT HAPPENS WHEN WE HAVE 200 USERS ALL OPENING LITERALLY HUNDREDS OF TABLES EVERY DAY? CURENTLY WE HAVE RUNTIME LOADED ON THE NETWORKED PC'S AND ALTHOUGH SOMETIMES A LITTLE SLOW, IT WORKS VERY WELL WITHOUR SHADOWS AND LOCAL COPIES(EVEN THOUGH THEY DON'T EXIST IN VER 1.02). IT JUST SEEMS TO BE A VAST AMOUNT OF LOCAL PC OVERHEAD WHEN THERE IS SUCH A LARGE APPLICATION. ATTACHED IS A .JPG IMAGE OFOUR MAIN MENU. REMEMBER BACK TO THE CARD STACKS OF VERSION 1. WE HAVE 16 CARDS IN THIS APPLICATION, MANY OF WHICH CALL OTHER APPLICATIONS.

[whanigsberg]

Tom,

It is not really a vast local burden, merely a single folder on the local machine's drive which holds your application's graphical elements.

As we all know, drive space is cheap and network bandwith is not. So we can conceptualize the optimization issue as a purchasing decision: whether to achieve a specified level of performance by buying bandwith or local drive capacity.

As with all such decisions, one does the math for the specific conditions. In this case, the decision is usually easy since often there is unutilized local drive space which makes optimization free. Since networks always run out of bandwidth sooner or later you should probably optimize.

My A5 application currently has 20 users on a Novell network. Optimization has dramatically improved performance without causing problems. These 20 coexist with a much larger number of others who use the network for diverse other (non-Alpha) applications.


Bill

[Thomas Henkel]

From what I read, a5 makes a local copy of all the dictionary files for each table that is openend by the user. Like I stated before, we have literally hundreds of tables in this application. Does this mean hundreds of ddd,ddm,etc files on each local machine? Do the users need to refresh when we make updates to screens, reports, etc? Did Alpha slow down considerably since version 1? We have mde the committment to upgrade to the latest version (4 or 5) of Alpha software, but because of the size of our application(s), it has been a very slow and arduous process.

Again, I am not disparaging the new version, just trying to understand.

[Pat Bremkamp]

Thomas,

You have hit on what will probably be the biggest issue for you...updates.
In our case, we have a much smaller network and application, so we use an autoexec script to check the date of the latest udate using a script based on Dr Wayne's ideas. If there are any updates, the shadow is automatically updated before the main menu comes up.
The good news for you is that the decision to optimize or not can be made machine by machine. Pick a couple machines and try it. If it is successful, add a few more. You don't need to do them all at once. We use it on some machines and not on others. It works very well to reduce the network traffic and speed up menu and form changes.

Good luck.

[JohnZaleski]

Tom,
I recently converted a large application ( close 200 tables and sets ) from a5v1 to a5v4. I had every reservation that you had. I agree with Pat when he says one of your biggest issues will be when and how to refresh your application. My experience on a fairly large app is that there is no decision as to optimize or not. You will have to optimize. It will run brutally slow without optimizing on a very large application. However, when optimized, my application runs at least as fast and sometimes faster than it did on a5v1.
John

[Thomas Henkel]

Thanks,

I guess that once we really get this conversion done, we wil need to explore the issue. All of your input has helped.

[tlyon]

One important issue to keep in mind, Tom, is that if you do optimize (and you will see great speed improvement, especially if you are using sets) is that there are two different conditions to be aware of. The first is that if a form or report is modified, the workstation must refresh shadow. The second issue is that if a form, table or report, etc. is *added* to the database, the workstation must then Network Optimize. A Shadow Refresh will not bring in the new additions to the database. This can be a real pain, but I presume Dr. Wayne has an appropriate script that can help automate that process as well.

Tom Lyon

[Thomas Henkel]

Maybe I just don't understand. What happened between ver1 and ver 4 to slow things down so much as to NEED shadows and local copies? Version 1 was (and still is) quite quick with loading forms, cards, etc.

[tlyon]

Good question. I started with v3, now at v4 and waiting for v5 (skipping 4.5). I know that v4 is a great deal quicker and more reliable than v3. I presume v5 will be that much better than v4 as well. I hear you, though. I still use Alpha Four version 2 on a daily basis..for one reason. It hasn't crashed in *FIVE* years. Nary a single corrupted index. It's only a stand-alone version, so that's why we use Alpha Five, too. The data tables are copied nightly for use in Alpha Five. I'll never moth-ball that one :)

Tom Lyon

[Thomas Henkel]

My response times in version 1.02 are, literally, seconds. Am I supposed to believe that they will drop off so dramatically in a newer "better" release? Granted, on some screens where we do incredibly intense calculations, the response can seem painfully slow, but we just look at the work performed instead of having to do it by hand, and our people are very happy. Should I start preppng them for a fall?

[JerryBrightbill]

Thomas,
I wouldn't worry too much about the speed of V4 vs V1. I converted part of a calendar app from v1 to v4. Loading and calculating the main form in v1 was fairly slow. The speed in v4 was about the same. This was on a standalone system. There may be speed differences in other operations, but I haven't compared an identical operation in each to verify. The big change in v4 to network optimization results in speeds across a network to be very similar to speeds on a standalone. This makes sense, since the only think coming across the network is the basic data. All forms, reports, etc are loaded locally. All calculations are also done locally.

There are so many new features in V4 and v4.5 that an upgrade is very worthwhile. But be advised, if you have a complicated app, it is NOT a straight conversion. If you search the forum, you will find many discussions of the issues involved. I have an app in v1 that will stay in v1. It is just not worth the effort to convert because of the need to rewrite a large number of scripts.

Jerry

[Peter.Greulich]

Several points to take into consideration:

I believe ver.1 is faster that ver. 4, in the same way that AmiPro is faster than MS Word. Window 3.1 apps simply have much less overhead that Win9x/2000 apps, and as you know, A5v1 is a Win 3.1 app, period.

Ver. 5 will update tables and sets when you refresh. However, everytime you change one form or report, you will have to refresh your entire application. Obviously, given your large application, this will take some time for each individual user. If you do this once a day, it is a real pain. Selwyn said in a previous post some time ago that ver. 5 would not selectively update only changed files. Personally, I think Alpha is insensitive on this point. They seem to assume that all Alpha users are developers who only update a client's apps once or twice a year. Those of us who write apps for our own company or, as in your case, government agency, are constantly modifying and adding to our application, often daily. In my own case, with about 10 users, and an app that is a little over 100 tables and sets, it takes about 3 minutes to refresh or optimize - a long time by computer standards. If A5 only updated the changes, the refersh would take just a couple of seconds. I hope Alpha addresses this concern that many of us have in a future patch.

Peter

[Tom Cone Jr]

Peter, in my experience it's not necessary to update the entire application when you change a form or report. You just have to update the data dictioniary fiels for the affected table or set.

Changes to index definitions, and new or changed 'global' scripts or functions are a different case, and would require updating other files, but even then it's not necessary to refresh or 'copy' unaffected files.

-- tom

[Thomas Henkel]

Peter,
I have attached a picture of our main folder served from an NT4.x server along with a copy of our ver 1.02 Aplication. This applcation calls numerous other applications that are task-specific. Workers can switch between tasks ataany time during the day. If they were to havve shadow databases and local copies of dictionaries, it would become a maintenance nightmare. We are constantly making changes in response to user requests. The beauty of Alpha Software is that changes can be made on-the-fly, and put right into production. If we had to regresh upwards of 250 workstations each time we changed anything, we would never get anything done.

[Tom Cone Jr]

Thomas,

One idea you may want to investigate is automatic refreshing of workstations. Using xbasic scripts the workstation looks for a time and date stamp on the server when it logs on... if the time and date stamp in the file on the server is different than the one stored locally, the local application refreshes itself, and then updates its local time and date stamp file, so that the refresh will not occur the next time the user logs on.

The next time you make a change to a form or report on the server, you manually update the time and date stamp file there... so workstations throughout your office will update themselves when they next log on...

-- tom

[Thomas Henkel]

Tom,

Thanks. Once I actually get this monster converted nad into test, I will check this out. We already use a product called ground contreol to update certain files on the PC's when they boot. Maintaining a network this size with 4 programmers/techs requires many automated procedures.

Tom

[Thomas Henkel]

by the way,

what on earth are you doing scanning the forum at 5am??

[Peter.Greulich]

That is true, Tom. But it becomes a pain to manually copy dictionary files to 10 different stations, so I rely on a variation of Peter Wayne's shadow update script to do the job.

Peter

[CALocklin]

This string brings up a question...

If the data dictionary files are simply copied to the local drive when optimizing, why couldn't we just create an "update definition" file that indicates which dictionary files need to be updated and set up a routine at the local drive that would check the date and file name then copy them to the local drive as req'd? This would not handle addition of new/restructured tables which would still require a full optimization but it could handle copying set files and data dictionary files when forms, reports, other layouts, or field rules are changed. It could also handle the .al* files which hold the global scripts.

A routine like this would allow the updating of 1 data dictionary file in those cases where many tables/set are used. (Although I can't imagine why anyone needs 'hundreds' of tables although I've seen that kind of thing mentioned here numerous times.)

When I get time - in about 6-8 months!! - I'll take a look at it. In the meanwhile, maybe somebody else has the time??

[Peter.Greulich]

Cal,
I may be mistaken, but I don't believe ver. 4.5 has a file date/time stamp command, although I do believe ver. 5 does.
Peter

[csda1]

Hi Cal,

The Time and Date stamps of files are not available through Alpha 5 V4.x and Win API calls for these do not work either in V4.x. Calls to DOS to extract the information have some other issues associated with running DOS Boxes (particularlly in Win 2k and beyond-e.g. Win 2k does not close the DOS box in some systems that work fine in Win 9x/ME and vice versa) Version 5 does add this Time/Date features.

Updating the files can work to a degree, but if you add a table (via XBasic) to a database (for the purposes of running a report) and then drop it, the time and date stamp are changed on the Adb file. This creates some issues trying to use the adb file as a reference.

Nevertheless, it can be done.

Your comment about 100's of tables I tend to agree with. I often create 20 odd tables that are lookups for fields (as opposed to embedding in the field rules), but I never seem to have that many that are more than a token size, and certainly not that many.

Regards,

Ira J. Perlow
Computer Systems Design & Associates
csda@mediaone.net