I've read most threads on full program stacks, but my situation doesn't seem to come, so can you help?

I am getting a "Program Stack Full" issue that isn't caused by the usual means.

I have a subroutine (not expendable) that updates tables on other volumes by attaching the table on that volume opening the table, reading then writing. The reading and writing is in a loop, the "open" only happens once.

I found that if the loop goes round more than 15 times, the stack would fill.

Please note - in the loop there is no {} or call commands just read and writes.

On putting a break at the end of the loop I found that for each read of the loop there are 5 items that fill the program stack. They are

$SymbolicField1yDICT.MFS@svmRTP57@vmy0000000000137VolumeName\Rev26842.LK

$KeyFieldNameyDICT.MFS@svmRTP57@vmy0000000000137VolumeName\Rev26842.LK

$SymbolicField2yDICT.MFS@svmRTP57@vmy0000000000137VolumeName\Rev26842.LK

$DescriptionField_XREFyDICT.MFS@svmRTP57@vmy000000000137VolumeName\Rev26842.lk

$DescriptionFieldyDICT.MFS@svmRTP57@vmy000000000137VolumeName\Rev26842.lk

The y is a y with a squiggle on top

Both symbolics use the KeyField in their calculation. But both symbolics are not used in the loop, nor any indexes, nor is it a select routine

Why is it doing this?

How can I Stop/Clear it?

TIA

Claude

Is this a recursive subroutine? Have you tried making it expendable?

Claude,

Not sure, but the you may be adding symbolics to the stack because of indexing. An easy way out might be to call an expendable subroutine from within the loop to open the file and do the reading and writing.

David

I have been able to locate the filling of the program stack to the following:

Within the loop…..

Attachtable_sub(orig.location,TableName)

Open TableName to FileHandle…..

Read Details from FileHandle, Rowname

…

Modify parts of Details

…

Detachtable_Sub(orig.location,TableName)

Attachtable_sub(new.location,TableName)

Open TableName to FileHandle…..

Write Details to FileHandle, Rowname

Every time the program passes through this part of the loop, the additional items get added to the program stack.

The TableName and Rowname are the same for both locations

I've tried putting the read and write to expendable subroutines/functions but this has had no effect

Any further suggestions appreciated

Claude

What does "Modify parts of Details" do? What does your loop structure look like? Does it loop by calling itself?

OK some more info for you

The loop is a simple for/next

I have a user entering data on a amv in a collector window

on the

The items are to be sent to another branch (volume)

I count the No of used mv lines and I do a for/next based on that No.

The first prompt of each line of the mv has a product code

I check the branch to see if it has the product code

If it hasn't, I read the code from the branch I am sending it from

Remove things like qty in stock, last trans date etc.

Write - in effect a clean product code - the details to the new volume

The modifying is innocent - just zeroing and nulling various fields before writing to the new location.

Does this make sense?

I do this all the time within a single volume - it only seems to get upset when I'm doing it across volumes.

Claude

Does it still happen even if you put this whole thing in an expendable subroutine:

Attachtable_sub(orig.location,TableName)

Open TableName to FileHandle…..

Read Details from FileHandle, Rowname

…

Modify parts of Details

…

Detachtable_Sub(orig.location,TableName)

Attachtable_sub(new.location,TableName)

Open TableName to FileHandle…..

Write Details to FileHandle, Rowname

i.e.

For I=1 To N

Call MyExpendableSub(a,b,c)

Next I

David

Thanks David,

That finally cracked it.

I've just spent the last two weeks trying one workaround after another to - in effect - solve the woeful pickle Arev gets into when you are using the same table in multiple volumes.

For those of you interested here is what I found.

Don't store the file handles of files of tables on other (unattached volumes) - If you update the dictionaries on a table with symbolics relating to the key of that table, serious crashing will occur.

Do not use SetAlias (ever) as if you have more than 3 volumes you will find it can't read the DICT of that alias

Don't attach/detach tables and read/write them within your normal subroutine - make this happen on an expendable subroutine external to your loop. You'll take a performance hit, but who will notice with todays computers?

Make sure your subroutine is expendable as having it declared (and not expendable) while still not using the call command, still results in a Full Program Stack.

I'm nearing the end of this painful journey - I hope. My client will be putting my rewritten re-write through its paces next week. Wish me luck.

Claude

View this thread on the forum...