A new variable scope

[MikeC]

Re: A new variable scope

It sure sounds like a schizophrenic exercise in dichotomy, doesn't it?

Not really......but maybe the allusion would be better using Multiple Personality Disorder??? Then I would agree. Unless you did intend to allude that it was some sort of psychotic dichotomy. Picky, Picky I know---but G you were part of a thread in which I stated that the two words on my "Pet Peeve" list were "ain't" and "schizophrenia" ! :D

Now--I got that out of my system! :)

How about your imaginative answer that all have been hoping to hear (this time Please don't disappoint us by NOT letting us know.) ???? Always enjoy your somewhat sideways twist on things...many times being just so simplistic that others skim over without even seeing them.

[G Gabriel]

Re: A new variable scope

Andrew:

Gabe:

You now have me really confusedwith your last post.

I read some excellent suggestions in this post about where and how to store variables.

Are you still saying "the answer is yes or is the answer no"

Tom

I am no John Kerry nor Mit Romney... nor what's his face?
The answer is still yes. No flip flopping here..

Mike:

Unless you did intend to allude that it was some sort of psychotic dichotomy. Picky, Picky I know---but G you were part of a thread in which I stated that the two words on my "Pet Peeve" list were "ain't" and "schizophrenia" !

Well, ain't schizophrenia a psychotic dichotomy?

[G Gabriel]

Re: A new variable scope

OK.. here is how it works..

I am not going to touch the variables or save them anywhere. Leave them alone. Let variables be variables. You create them when you need them, use them and then they die. That's their life cycle and that's why they are what they are, variables. So, what are we going to do?

Well, how do variables come to being?
With the exception of layout variables, the scope of which is so limited it is not worth including here anyway; variables are created when you dimension them, implicitly or explicitly, by a script (or a function).

When a bullet leaves the barrel of a gun, it takes the imprints of the barrel. That's how they identify bullets in ballistics. So, if you want to change the ridges on a bullet, you could grab a bullet and scratch some ridges on it, OR, you could change the ridges in the barrel. We will leave the bullet (the variable) alone; we will change the barrel (the script).

Instead of saving the variable, we will alter (update) the script that creates it, and hence the variable. Normally, a variable gets created, gets assigned a value per your script and if you exit alpha, the variable along with it's assigned value will be wiped out. But, what we will do differently here is, before existing alpaha, we will change the script to have the newly assigned value as the base value for the variable, so when you reboot, the variable gets created again but now it will start from where you left off last time you exited.


To illustrate, say you have a primitive script that says:
dim x as n
x=1

If you run the script, x will be created and gets assigned the value of 1. If somewhere down the script x gets assigned a new value, say 5 and then you exit alpha then reboot and run the script, it starts allover again with a value of 1.

What we will do differently here is, before exiting alpha (or any time during the session) we will alter the script to make it say:
dim x as n
x=5
Next time you reboot and run the script, it gets reborn again but now it grew up to a value of 5 instead of 1.

What is the practical application of this? Quite a bit and quite significant.
I will get to that later, gotta go for now but it is not hard to imagine what you could do with that.

[aschone]

Re: A new variable scope

it is not hard to imagine what you could do with that.

Very true, but also seems like a lot of effort for saving a variable for use after a reboot. What is the reward for all the effort put forth to change a script? Why should I use this method over say a text file, registry, or a table?

Ira-

In general, do not write to the Data dictionaries and Adb files as these are really for development, not dynamic usage.

Isn't modifying the script to store the new updated variable along the same lines as modifying the data dictionaries?

[Doug Page]

Re: A new variable scope

Sounds like an old batch file technique. Generic batch files were quite "dumb" but it would work in a pinch. Alpha is a lot "smarter" and I am not sure why one would want to do this. Hopefully you will reveal your answer.

Frankly, I am more inclined to agree with you about what is and is not a variable. If it needs to be saved for later use, it really is not a variable and should not be treated as such. What happens if your machine locks up on you after your "variable" has been updated but not written anywhere?

For my taste, I hate things being stored in the registry, have written date to files like the old ini files, but prefer the stability and portability of keeping stored data in a defined table.

[G Gabriel]

Re: A new variable scope

Andrew/Doug:
I am not sure why you think it's a lot of effort. Perhaps you read what I said to mean that I am going to alter the script manually. Not at all. Altering the script will be done dynamically as a part of whatever script you use.

Perhaps the best way to show how that works is with an exapmle. Let's take a very simple one. In a recent thread someone asked: I want to allow test users to enter a limited number of records in a table on a trial basis. The conventional response would be to identify the user, count the number of records created by the user then prohibit entery if that number is reached.

Here instead, I will write a script that identify the user, each time the user enters a record, the script increments the variable and once the user reachs the upper limit, s/he will be prohibited from entering new records, if not, upon exit I would update that script once with the new value of that global variable so when s/he reloads alpha, s/he starts from that number.

A more broad and much more useful application: autoincrement.
If you do your own autoincrement and there will be many circumcetances where you need to, traditionally you would query the table for the highest value and then increment it. Here instead, I will have a global variable holding the count number, every time you enter a new record, the global variable gets incremented. Now we are talking about a speed demon. You don't have to query the table (with all the imedements associated with that) at all, it's all readly available in a variable that is stored in the cache. When you are done and ready to exit your program, you just update the script to the latest variable numer.

Even yet a more broader application and much more useful:
Suppose you want that autoincrement value to come from several tables? now instead of querring all these tables, you only get your value from the global variable and when done, alter the script once upon exit.

Even yet, what if you want to autoincrement on a network and want to have unique but sequential vlaues?

[dpawley]

Re: A new variable scope

Although this method works, I don't think it would work in a multiuser environment. The text file, registry or database seems to be a beter option.

[Marcel Kollenaar]

Re: A new variable scope

Sounds, good.

[G Gabriel]

Re: A new variable scope

David:
I can't comment on whether it will or wll not work in a multi-user enviroment as I am not sure if a script saved, say as a single script in the code tab, can or cannot be seen and run by remote users. If it can, then it could be used in a multi-users enviroment and would be a great alternative to what has been suggested in the past relative to that subject.

[michaelwpayton]

Re: A new variable scope

David:
... would be a great alternative to what has been suggested in the past relative to that subject.

Could you please expand on why it would be a 'great' alternative?

[G Gabriel]

Re: A new variable scope

What has been suggested in the past, and I just read that article by Dr Peter Wayne couple of days ago, is to create yet another table to hold the value for the autoincrem field, lock and obtain the value from that table and update the table each time a user on the network enters a new record.

On the other hand, if you are able to see and run the script remotely and have that value in a variable in the cache not in a table, you can increment the script and hence the variable, add your record without locking any tables or worrying about duplicate values.

There could be the case where two users are trying to update the script at the exact same nano-second, the odds of which are less than being hit by lightening, but yet is possible. I am sure I could add some safeguards there, but I haven't gone that far as I am not sure if it will work on a network in the first place.

[Doug Page]

Re: A new variable scope

G,
First off, I didn't say that it would require more work, just that I didn't necessarily like the idea. If you are going to change the script, then you obviously have to read and write the file. And it better get locked if in a multi-user scenario. Even in the old batch file technique I referenced above, in a multi-user setup, we still had to provide away to lock out other users if one was doing this process. So are there some kind of tremendous time savings?

[Al Buchholz]

Re: A new variable scope

There could be the case where two users are trying to update the script at the exact same nano-second, the odds of which are less than being hit by lightening, but yet is possible.

One word answer -

Murphy

Murphy didn't event computers, but he certainly declared his laws with computers in mind.

I have client's systems with only 2 users and they manage to produce that type of collision and therefore data integrity issues follow. Unfortunately it takes only a few data integrity issues to drop user confidence.

Dynamically changing a script is a tool that has it's place, but not as a multi-user file system replacement.

[G Gabriel]

Re: A new variable scope

Doug:
Just using the autoincrement exapmle: If you want to query your table for the highest value and let's say you have a large table, you could perhaps use tablemax() which is a lousy function. Or, you could use dbmax(). While this is a much better function, yet it does not come cheap, you have to have an index and that index gets updated upon each edit, and if you are lucky, it won't get corrupted or dropped. That's a whole lot of overhead, trouble and vulnerability when you could simply have your value in a global variable and no, you don't need to update the script each time you enter a recod (contrary to the traditional method where have to query the table each time you enter a new record using tablemax or dbamx), you only have to update the script once upon exit.

[G Gabriel]

Re: A new variable scope

Al:
Just as you would put safeguards (by locking the table) I suppose I could lock the script. Again, I haven't investigated that yet, but that's not the only usage for this idea.