A new variable scope

[G Gabriel]

Re: A new variable scope

MikeC:
Again, that is a bug in relation to alpha translating the code to xbasic, NOT the process of SAVING.

OK, forget about AS. Just write an xbasic script, edit it and save it a million times and let me know if you had a problem simply because you edited & saved it? that's my question.

[michaelwpayton]

Re: A new variable scope

MikeC,

When you do what G has suggested... make sure you have 20 or so guys on your network editing and saving the same script at the same time... :)

[csda1]

Re: A new variable scope

Hi Mike,

You can no longer say you haven't heard of anyone having this problem now...

It has happened to people reporting here, although it seems to me, rarely. Changing a script in development (even if people are using and sharing it - which means they are not optimized), is a relatively low risk as the changes are relatively infrequent. Changing it by running XBasic code that might be doing it a lot increases the risk to the percentage of increased time for each write. Once the network starts to get very loaded, this might go up exponentially in risk, as the risk of network collisions increases (It actually is exponential for all, but approximates to linear for scattered times)

If you trash your data, you typically have messed up one record's data. If you trash a script, you could crash the operations of your application. I know which one I'd rather have (plus you must share data - that's the point of a network!)

Of course, if you don't work in a networked environment, the risk is probably 0, as there is no sharing and everyone has a backup(?), right?

I would think that if this is a viable way though that a database compact would be in order wouldn't it??? Something that normally would not have to be done in a runtime situation but if scripts are being changed then think this is a necessity

Memo fields (either data dictionaries, or tables) only grow when adding a new item or if the changed item has gotten bigger than the previous largest size of the entry that was stored. If it is smaller, it just uses the same memo space and the rest of that space is unused. But if the code gets bigger, by even 1 byte, it's a new entry at the end of the memo file. This means it is likely it will grow for most uses.

In this respect, writing a script of the type of usage described to the data dictionary probably might grow to some maximum, but probably would never go beyond that point, using the same space repeatedly after some point of growth. After a compact, this growing stage would repeat.

If it grows without limit, then it needs to be compacted at some point, which can only be done with exclusive access to the tables and/or dictionaries.

[MikeC]

Re: A new variable scope

NOT the process of SAVING.

Agreed...obviously it is in relation to DELETING some script.

Just write a simple online xbasic script, edit it and save it a million times and let me know if you had a problem simply because you edited & saved it?

Reread my last post.

Am afraid even with my abundant amount of time to banter I am now finished... that nothing said further will cause enlightenment and I have made my point, will stand by it, and others can take it for what they will...I can see where my credibility stands with you.

[MikeC]

Re: A new variable scope

Ira,

Thanks! Some useful information.

[G Gabriel]

Re: A new variable scope

I am not going to try anymore either. Evidently you are not able to see that there are two things at work here where your bug is:

alpha is TRANSLATING your AS to xbasic, you changed your code, came back and changed it again, and then found the bug. The bug is in TRANSLATING FROM AS TO XBASIC. There is no evidence whatsoever that the dictionary got corrupted, or is there?

To isolate the issue, do the same code in xbasic, change it, re-change it and save and see what happens?

The "leftover" you refer to, is in TRANSLATING your code from AS to xbasic.

In my scheme of things, I am not using any AS to edit anything. I am dynamically editing a script with xbasic. I used the AS example earlier to approximate the issue to the minds of those who do use AS which seems to be the majority.

[JohnZaleski]

Re: A new variable scope

Gabe,
I find your original idea to make variable values persist a pretty good one. The following is meant to give either side of this disagreement a stronger leg to stand on.
How about a more vigorous test on your part. Create a script that changes another script . Put it in a loop of(your number) a million times. Run this script from several computers at the same time. This should guarantee some collisions. If they both finish without crashing compare the size of the alm file in bytes before and after. Also do it in an application that has a number of global scripts already. If the alm file is bloated, as happens when memo files are corrupted then you lose. If the memo files are not corrupted then you win.
john

[G Gabriel]

Re: A new variable scope

John:
You read my mind. That's exactly what I was thinking to do and then I thought to myself:

Why on earth am I trying to sell people on an idea when, as we all know, there will always be some people who just simply can't even attempt to think of other ways to do anything and those that don't like their comfortable bed shaken?

The word sell here is a misnomer, I am not getting anything in return.

Don't take me wrong. I don't at all mind people trying to poke holes in my theories. That's the way it should be and it helps me rethink everything. But I think people should go beyond that and say: maybe there is something there, maybe we ought to test it first or maybe we could improve on it.

That said, I am at a big disadvantage and handicap. I am not on a traditional network, I am on a "virtual" network so to speak. So, any tests I do, I cannot tell you if it will work on any other network. I was hoping that some open minded person might say: I am going to look into this and test it.

What is a "virtual" network?
I had hoped to avoid this, but I guess I am going to have to explain. There couldn't be a worse time to get into this but now.

[DaveM]

Re: A new variable scope

John has a good idea.

Seems I heard somewhere( in a post here?) that when you resave a script, form, udf, etc. that a new record is added where the other file record was and the first was NOT deleted(just marked) until a compact. Is that true???

Dave

[G Gabriel]

Re: A new variable scope

I ran a loop of a 100 with a simple one-line script.
Took about 6 seconds. Ran it 10 times, i.e. 1000 loops. ALM file prior: 2kb, after: unchanged.
Don't know of any end-user who could enter 100 records in 6 seconds! Mind you, the idea is not to run each time you add a record, but only once before exit and furthermore, all you need is a one-sentence script.

[JohnZaleski]

Re: A new variable scope

Gabe,
I don't think a thousand loops in a single user situation approximates the activity you might experience on a 10 user system with all users adding records to the same table using the script_load and script_save as an alternative to writing to a table for auto incrementing. I for one didn't see much of a problem using those commands only upon exiting. I'm not rooting for you or against you, but made the suggestion to run a test to simulate activity that might occur over a substantial period of time
I'm not familiar with the usage of the undocumented script_save command. Could you share the script you wrote?

[G Gabriel]

Re: A new variable scope

Gabe,
I don't think a thousand loops in a single user situation approximates the activity you might experience on a 10 user system

Perhaps I wasn't clear enough, I thought I was but maybe I wasn't.

I don't want anyone to edit the script with each record entry. That’s not the idea at all, but even for any other reason you end up doing that, it doesn't seem to have any impact.

Let me use a different example:
Let's say you want to build a table to keep track of your bank account. A newbish way to do that would be to have fields, among others, for debit, credit, amount and running balance. That's 4 fields. Then you use the running balance field as a calculated field increasing with credit and decreasing with debit.

A less newbish way is to eliminate the running balance field and use a calculated field in a layout that does the same calculation each time you enter a record. So, now you are down to 3 fields.

An even less newbish way is to combine the debit and credit in one, enter credit with positive number and debit with negative and the running balance will be calculated on the layout.

In any one of the above scenarios, any time you edit, add or delete a record, the entire table is recalculated to arrive at the running balance.

This table grows considerably and very fast and before you know it, you might have hundreds of thousands of records. For speed of calculations, you might choose to break your table by periods.

Here is my proposition:
I am not going to have any calculation of any sort, none whatsoever. Alpha does not have to go through these hundreds of thousands of records each time I make a change. All you have to do is dim a variable (for simplicity let's make it global and let's call it vbalance). Each time you add a record, whatever script you use to save your record will have a simple additional line at the end of it:

vbalance=vbalance+amout

And that's that. vbalance now is holding your running balance, You don't have to calculate 100,000 records to arrive at that figure. So, all we are doing here is updating the global variable, we didn't even touch the script. Can you imagine the speed difference between calculating the entire table as opposed to the same value being in held in a global variable that resided in memory?

So far so good. There is only one problem: once you exit alpha, that value will be gone since it's held in a variable. That's when updating the script comes in to hold the value over until your next session. So, the question is not how many records you enter or how many users, but rather, how often do you exit alpha? Once a day? Once a week? That’s how often you have to update the script.

I was responding to the assertion that repeated updating of the script might be dangerous! I ran 1000 updates in 6 seconds without a problem. In real life, you might have to do one update a day not 1000 per 6 seconds. It will take you 3 years to do a 1000 updates.

The other issue that might not have been clear enough is, I am not talking about a page long script. All you need is a script to hold over the value of the variable, something like:
dim global x as n=100
That's all you need. A place to park the value of the variable while the system is down.

And in my response to the other issues about power interruption and the like. Suppose you lost the value of the global variable as a result of that, all you have to do is recover it by running the calculation on the table. Hopefully you wont have to do that but once in a blue moon.

I am replacing all these table bombardments during data entry with a global variable. It's best to make the least amount of contact with the table as possible.

[Marcel Kollenaar]

Re: A new variable scope

Hi,

I agree with Jim Chapman and Ira about the table use.

The point is altering xbasic commands dynamically wether it is a variable or any other xbasic code construction. The best thing is to use a table and you have all the benefits of it such as security. In the table you put the commands you want to run or alter in text fields. You run the scripts with Evaluate_template().

Thats all: dynamic scripting is born.

I use a variant of this already with MSWord. I embed the code not in a table but in a Word document. I can send these code blocks to Alpha Five and Alpha executes them. It is what I call IPEXC (IP Executable Xbasic Code). In this way you can shoot very complex code blocks from MSWord to Alpha Five. It is a kind of Alpha Five slaved to Word (or Excel). However it is still in an experimental state but the results are promising.

[JohnZaleski]

Re: A new variable scope

Gabe,
Your example would not work in a multi-user situation.What happens as other users add records to your table?The vbalance amount is immediately incorrect and useless.If I am missing something here please explain.
I think you said somewhere that you don't do this for a living. You are certainly capable enough to handle problems as they arise. Those of us who develop apps for others must handle any and all problems for our clients, If you sense a reluctance to embrace a new idea, it is because if we don't look at the downside, we are not doing our best for our clients. That s why I would run the test as I first suggested: Force some collisions and see what happens. Also do it in an application with a sizable alm file, not just one single script.My philosophy on testing is to try my best to break it.

[G Gabriel]

Re: A new variable scope

If I am missing something here please explain.

You are not.

Only thing you might be missing is perhaps reading one of the previous posts.

This is what brought up the discussion earlier regarding shared memory as one solution. Again and as I stated earlier, I cannot tell you with certainty how to best handle it on a multiuser enviroment and was hoping that someone might carry the ball from here.

This might appear as a minor improvement if it works, but actually, it's only the tip of the iceberg. I haven't even started on other related issues with related concept.