A new variable scope

[webmaster]

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.

But you suggested this as a "great alternative" for autoincrment and you seem to be suggesting it is more reliable with less work.

If we ignore multi-user issues (which many of us can not), aren't you still flirting with disaster. What happens when in my single-user app the saved script sets the intial value of the global variable to say 10, I enter several records and then someone trips over the power cord of my PC?

Next time I start entering records, I will start at 10 and duplicate IDs. Right?

Yes, you can do more work by saving the script every time. But you've said we don't need to. And by the time you start doing all the required work to make this approach work properly, are you really gaining anything?

It seems to me that I must be missing something about this new variable "scope", so I'd be grateful if you could fill in the blanks for me if you have the time.

[G Gabriel]

Re: A new variable scope

What happens when in my single-user app the saved script sets the intial value of the global variable to say 10, I enter several records and then someone trips over the power cord of my PC?

That's a good point. You could also have a powe outage.
No all is not lost and no, you don't have to save each time (although saving a script is not that big of a deal and it does not in any way compare to saving in a table).
If that happens, and I hope people are not tripping over your cord every day else you really need a good lawyer, you query your table for the highest value and reset the variable.

[Tom Cone Jr]

Re: A new variable scope

Using one script to modify another.

I see script_load() to get the text of the script to be modified.

But I don't see a function to save it after edits have been made programmatically.

What am I missing?

[G Gabriel]

Re: A new variable scope

Tom:
script_save()

[Tom Cone Jr]

Re: A new variable scope

G, that's wierd.

Script_Save() is not indexed in the HELP file, nor can I find documentation on it by searching through the HELP file. I know cause I looked before posting. Oh well, live and learn. If there's documentation for it "out there" would appreciate a tip on how to find it. Thanks.

[Marcel Kollenaar]

Re: A new variable scope

Tom you are right. See this post.

[G Gabriel]

Re: A new variable scope

No Tom, I ran into the same dilemma and started a thread and Cal alerted me to that function. I was looking for it as I was thinking about this whole thing and couldn't find it anywhere in the help file.

I don't think there is any documentation for it, but it's there and it works.

To all:
I have a meeting I gotta go. I used autoincrement as an example, but that's not the only usage for this. think about any time you post to or update a table, this could be your ticket where you don't have to open that table every time you want to post or update.

[michaelwpayton]

Re: A new variable scope

In general terms... i.e. not just thinking of the Alpha environment... no matter where the "vairable" is stored, accessed from, written to, etc... you will have the "concurrency issues" to deal with. So, the only real question is what "solution" provides the "best concurrency control available" in any particular computing environment.

My guess is that in the Alpha computing environment, using it's db-based "concurrency controls"... regardless of if the file being used is a dbf or where ever Alpha stores scripts.... is as good as it's going to get. That is, unless/until, there is an Xbasic function which allows multiple workstations to share a memory location on one workstation designated as a memory-server.

I have actually programmed in that sort of environment... but it was at NASA... the computing environment was a cluster of computers designed to create a file-safe environment... and it was likely more expensive than most Alpha clients would be willing to spend to ensure that their next invoice number is correct. :)

[JohnZaleski]

Re: A new variable scope

I think the idea of continually writing to the adb file of an application is not a good one.
If a hardware glitch occurs while writing, then it is your application itself that could become corrupted..
As far as your first example goes, If someone had the initial unused application,once they were locked out by too many uses, all they would have to do is take the adb file from the original and overwrite the adb file in the current application.It seems almost too easy to reset the counter.
As far as its usefulness in an auto incrementing solution, that would result in many more writes( corruption possibilities ) than merely doing so on exiting.There certainly is a lack of available information on the script _save that would need to be known prior to trusting it in a rapid fire multi-user situation. For instance is it writing to the adb file in the server location or is it writing to the optimized local adb. Also as Michael mentioned, does it provide concurrency controls at least equal to the normal reading and writing to a dbf
Reading and writing to a dbf for auto incrementing is a time tested solution in busy multi-user environments. ADB multiuser writing could only be proven out thru exhaustive use in a real life situation.

[csda1]

Re: A new variable scope

Andrew:

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

Yes, saving a script is stored in the ALB/ALX/ALM files. Data dictionaries are properly shared as they are just renamed DBF files. However, they are not tested for this kind of activity, so it is possible that some activities (e.g a pack, shadow, etc) could potentially not be handled properly. Scripts (and most things in there), are read, changed locally, and then written back overtop whatever is there. Other users are not locked out during that process (whereas in a normal table if you are in change mode, all users are locked out until you save), except during a very small time during the read or write, meaning who knows who will write the last value?

Pre-beta versions of the CSDA Code Utility's Desktop Restore actually wrote a special script, to facilitate a Desktop restore and to have less impact, but this was only one time startup, and ultimately these were eliminated.

Also, if a database is shadowed, then it is normally referencing a shadowed copy specific to the user, and is not the shared dictionary on the network.

This method of code modifying your code is also potentially dangerous to the point that you can hang your code (That's why we use C and not APL for most programs!). E.g. suppose you had a line that set in a script something like this

dim global datevar as d
datevar={13/14/2007}

You will potentially cause an execution error that could be difficult to recover from if in a critical place (e.g. your autoexec script)

A table can store the same information and be a whole lot more accessible and shared or not shared. A record in the table could hold a value, and potentially only specific users or user groups could have access to it (by another field holding "rights". So a record could hold user only or shared data. Anyone changing the value would normally be doing by code execution, so the data would not be locked for long.

The issue of autoincrement via program control using anything that does not utilize proper sharing techniques is flirting with danger. The technique of using the database locking/sharing mechanism has been in use in the Alpha environment since Alpha 4 DOS days. When done properly (and it is not easy to do properly) it provides the proper safety. It would be nice if Alpha had provided an "Atomic" locking mechanism for code, but it does not, and that is why it is so difficult. It requires using mechanisms within Alpha that implicitly have these.

It all comes down to essentially having a "test & set" in a single operation that can't be interrupted, but it can't be done at a high level like XBasic. It can also lead to a situation known as a "deadly embrace", something akin to traffic gridlock, even when done right.

[G Gabriel]

Re: A new variable scope

John:
I know.. but that is the same argument some people used a 100 years ago or so that horse buggies and mules were much more reliable and time tested than automobiles.

I can't answer any of that. Perhaps alpha can. But one thing is quite clear to me: rewriting a one or two-line script cannot possibly be as onorous as locking/eding/updating tables & indixes. I can't imagine that, particularly if you have tables with hundreds of thousnads of records and several indices.

I did multiple runs of rewriting the script, it worked each and every time. I am not suggesting that people should just drop everythin and redesign their databses allover again. It's something to think about and consider, maybe one day it will become the norm and horse buggies become a museum item. Maybe alpha will take note of that and provide for more reliability in the adb if it is lacking and I don't know that it is.

Mike:
Shared memory sounds like panacea and it will take more than alpha to accomplish. Your OS must allow you access to the same memory slot and I don't see that happening anytime soon, that is unless Bill Gates is reading this! Even then, I don't see how a shared memory will resolve all concurrency issues. Perhaps a shared memory will make it possible for all machines to access the same variables, but it wont resolve the issue of triggering or saving the same script at the same nano-second. I believe you do have to lock the script and that shouldn't be very difficult with an on/off flag. The locking will only last for milliseonds, the time needed to save the rewritten script, unlike locking the table for minutes or perhaps hours while Suzie is editing a record, answering the phone, putting paper in the fax machine, sending email, eating lunch, filing her nails and adjusting her makup.

Ira:
I am not buying any of these hypothetical arguments, but assuming that all these disasters happen, who the heck cares?! It is not the end of the world, you could reset the variable by quering the table once for the highest value. Same scenario like that guy who tripped over the power cord.

When was the last time a table pack destoyed your dictionary? and if it did, don't blame it on my script.. next thing you are going to blame me for the Korean war!

[Jim Chapman]

Re: A new variable scope

This thread appears to me to go around in circles. First off, addressing the issue of creating your own auto incrementing routine, and querying a table to get a value to auto increment, Peter Wayne’s approach is the way to go, but there does not need to be “whole lot of overhead, trouble and vulnerability” in querying the table. Although there are issues, which IMHO would be much less than modifying the script with each use, one could do this to get the value to increment:

t = table.open("customer",FILE_RO_SHARED)
t.index_primary_put()
t.fetch_last()
vNewIncrementNumber = t.incrementNumber + 1
t.close()

One could argue about the overhead of opening and closing the table, but there are other options here as well but the real issue is timing and muti-users hitting the table, and IMHO the reason Peter Wayne’s approach is preferable is because it isolates the process of getting the incremented value from the repository of the data.

Beyond this, the whole discussion is about ‘which file format is best’ to store a value. After all, what is an Alpha Five script but a file, or more correctly a portion of a file, a given entry in a memo field. Alpha Five stores scripts predominately in the database library (can also be stored in a given table’s data dictionary, as an AEX file or if you want as a text file executed by an evaluate_template() function call), specifically the *.alb and it associated memo file *.alm. Remember that these file formats are really just plain old dbf file formats with different file extensions.

If I am understanding this whole thread, what it being proposed is to change the script ‘on the fly’. So in effect this means modifying the *.alb and *.alm files within a muti-user environment. If we are talking about a single user environment, the whole issue of overhead is insignificant. Do we really want to be modifying the data dictionary memo fields ‘on the fly’? My opinion is we really don’t want to do this, especially without any real gain in functionality.

So boiled down is it best to store values in:

The registry?
A text file of some type?
A table (dbf)?
A table & memo file (script file)?


Jim

[DaveM]

Re: A new variable scope

G,

I believe it can be done in shared memory. Ever hear of a ram drive? We used them big time when compiling clipper apps. Compile on an old hard drive = 2 hours, sam compile on a ram drive 10 minutes.

Share it over a lan( if possible?) and you have a speed demon?? Or maybe not.

I think I had a small alpha app in a ram drive once and it FLEW!

Dave

[forskare]

Re: A new variable scope

Man, what a thread. Much of what was said is over my head to one degree or another. Whew!!!

What I do understand and enjoy is listening to the interaction. I like the way Gabe is thinking "outside the box". He never said his idea is the way to go. Rather, he posed an idea in the form of a brain teaser to get others to think.

Gabe didn't expect everyone to agree nor do I think he wanted everyone to agree. I think it's a very clever way to provoke other's thoughts and ideas.

Venturing "outside the box" is a very valuable tool to exploring new ways of doing things.

kenn

[G Gabriel]

Re: A new variable scope

This thread appears to me to go around in circles. First off, addressing the issue of creating your own auto incrementing routine

How did this thread end up being about autoincrementing when I only used that as an example?! In fact the example I used prior to that was about keeping count! If autoincrementing is a bad example, well, can't you use your imagination as to what can you use such an idea for and offer better examples instead of trying to beat me and my ideas to a pulp? If people can't understand or don't want to understand what I was talking about all along, all I could say is:

Folks, please don't shoot me, I was only joking.. the earth is flat, just look at it, it's flat!