form in use - why?
I'm tidying up some routines in a datease 6.52 application after migration and have come across a problem with a few DQL's regarding file in use.
I've stripped out everything and made a basic demonstrate of the problem:
-- DQL start
for FORMA ;
modify records
FIELDA := 0.00 .
end
for FORMB with Picking Week between 01/12/09 to 31/12/09 ;
modify records in FORMB
FIELDB := 1 .
end
-- DQL end
The issue is caused by the second FOR routine. I get a time out telling me FORMA is in use. It shouldn't be as I closed FORMA with END before starting the next FOR loop. This issue I've already come across in 2 DQL's to now, both of which worked fine in 6.52 but in 7.2.2.747 the second FOR loop can not run as Datease hasnt closed FORMA from the first FOR loop.
Is there a simple fix to this or has something changed? Thanks.
By: Simon Brown posted: 19th January 2010 - 13:21
Replies
Adrian Jones at 20th January 2010 - 18:38 says:
Hi Simon,
Try wrapping the entire procedure in an outer for loop. You'll need to pick just one record for this, but you don't need a dedicated table as such. This:
for AnyOLdTable ;
-- Do the stuff as above
break . -- to stop the outer for after one record
end
Also, your syntax on the modify looks odd. Surely you should have:
for FORMB with Picking Week between 01/12/09 to 31/12/09 ;
modify records in FORMB
FIELDB := 1 .
end
See if that makes any difference.
<a href="http://www.n10net.com">Adrian</a>
Adrian Jones at 20th January 2010 - 19:10 says:
Hi Simon,
Try wrapping the entire procedure in an outer for loop. You'll need to pick just one record for this, but you don't need a dedicated table as such. This:
for AnyOLdTable ;
-- Do the stuff as above
break . -- to stop the outer for after one record
end
Also, your syntax on the modify looks odd. Surely you should have:
for FORMB with Picking Week between 01/12/09 to 31/12/09 ;
modify records in FORMB
FIELDB := 1 .
end
See if that makes any difference.
Adrian Jones at 20th January 2010 - 19:13 says:
Hi Simon,
Sorry -- screwed up on thes postings. Be nice if there was a means to edit what had just gone up.
The last bit was suposed to show that the 'in FormB' part of the modify records should be removed.
Cheers,
Simon Brown at 21st January 2010 - 13:41 says:
Sorry Adrian I wrote it wrong to the screen, the procedure should read
-- DQL start
FOR CONTROLFORM ;
for FORMA ;
modify records
stockbefore := 0.00 .
end
for FORMB with FIELD1 between 01/12/09 to 31/12/09 ;
modify records in FORMA
stockbefore := stockbefore + 1 .
end
BREAK. -- CONTROL FORM
END -- CONTROL FORM
-- DQL end
As you can see I have included an outer loop (I have a 1 record form for that purpose that I use elswhere! :) )
But even with the outer loop the same problem arises.
As an after thought I replaced FORMB with another form and the routine didn't lock, but with another form it still it does.
So I'm now starting to think this has something to do with how my relationships are set up. Some have a unique relationship name, but old ones don't have a relationship name; again coming from my early days when I didn't understand it's purpose, and to be honest I still don't but I tend to enter something in there and use it.
Any thoughts Adrian?
Adrian Jones at 21st January 2010 - 15:18 says:
try adding an ad-hoc name to one of the FormAs
e.g. modify records in forma named "secondtime"
Cheers, Adrian
Simon Brown at 21st January 2010 - 17:17 says:
Hi Adrian thanks for getting back to me.
In the meantime I've been deleting all none essential data and DQL's and fields and relationships to get a simple set of test data.
So I ruled out relationship problems, large tables, clustered data etc.
I've just found something after having a bare database with 3 tables, 2 relationships and a few records. The problem stems around INDEXing. If I go in to FORMA and untick INDEXED the routine works sweet as a nut. For reference it is this indexed field that forms the relationship with FORMB.
So now it's a case of either indexes don't work properly or you can't have relationships with indexed fields. Not sure what yet.
Simon Brown at 25th January 2010 - 12:20 says:
OK after having a play i've found the culprit I think, but unsure what is happening. It is ultimately to do with file locking. In preferences under APP DATA ADMIN, PRINT LOCKING, if I change Data: Lock Files to Lock Records it works. Change it back and it doesn't work again.
So whilst Data: lock files doesn't work, if the box below; Files is changed from files to records it now works this way too, but locking FILES doesn't.
So ultimately file locking mucks up everything, answer is to lock records. Dataease has always made a mess of locking, looks like the mess is now taking a different path!
Any further thoughts?