Locking
Peter Rousseau
I can't get the unlock part to work. Would someone tell me what I am
doing wrong, or missing. Thank you.
method open(var eventInfo Event)
if not lock("Name.db","Full",
"Vehicle.DB","Full",
"Compass.DB","Full",
"Mail.DB","Full") then
msgStop("LOCKED!", "Need Exclusive Mode")
return
close()
endIf
endMethod
method close(var eventInfo Event)
if not unlock("Name.DB","Full",
"Vehicle.DB","Full",
"Compass.DB","Full",
"Mail.DB","Full") then
msgStop("STILL LOCKED!", "Can't get out of exclusive Mode")
return
else
msgInfo("","s/b unlocked now, form closing")
endIf
endMethod
Peter R
Mark Bannister
Peter:
What's not working? It works for me, pdox 9 latest Sp.
Peter Rousseau
When I close the form the locks do not release. I use the Tools menu item
"Display Locks" utility and it reports "Table Exclusive Lock". I then try
to open one of the tables on another machine and it displays a dialog box
saying the file is locked. I am using Pdox9 on one machine (doing the
locking) and Pdox10 on the other.
Peter R
Mark Bannistser
On local tables I have no problems. Try using an alias perhaps...or
maybe open table variables and try it that way....
Obvious, but make sure the code is executing. But in a breakpoint and
step through and/or turn errortraponwarnings(yes)
Bertil Isberg
Peter
<<
I then try
to open one of the tables on another machine and it displays a dialog box
saying the file is locked.
>>
Have you tried to open all tables?
<<
if not unlock("Name.DB","Full",
"Vehicle.DB","Full",
"Compass.DB","Full",
"Mail.DB","Full") then
>>
Do you geta TRUE returned from that statement?
What are you doing between Lock and Unlock with the tables?
Did you test exactly the code you showed ?
--
Bertil Isberg - CTECH
Paradox buglist:
online: http://w1.826.comhem.se/~u82608896/
FAQ newsgroup: corel.wpoffice.paradox-faq
David Portwood
I agree with Mark, use an alias when locking and unlocking your tables. In
fact, use an alias with any table operations because this will help you keep
your app independent of whatever the working directory might be.
Btw, it should be a rare occasion that you need table locks. Record locks
are usually sufficient. Why do you need these table locks, if you don't mind
me asking?
"Peter Rousseau" <Pe...@solutionsbyknight.com> wrote in message
news:413E2541...@solutionsbyknight.com...
Peter Rousseau
Bertil:
I must be getting a *TRUE* because the msgInfo comes saying can't get out of
exclusive
I am not doing anything witht the tables in between the methods:
I open the form ( the open method contains the lock code & a library is
opened)
I use the Tools|Security|Display Locks (from both computers) and confirm that
each table has an exclusive lock
I close the form ( the close method contains the unlock code)
I use the Tools|Security|Display Locks (from both computers) and it shows
that each table still has an exclusive lock
The only extra code I didn't show was the opening of the library in the
:open: method
if not Bluelib.open("Profiles") then
msginfo("Problem","Cannot open library")
endif
setPosition(1000,1000,7035,5800)
progmssg1.font.style = FontAttribBold
progmssg2.font.style = FontAttribBold
progmssg3.font.style = FontAttribBold
progmssg4.font.style = FontAttribBold
progmssg5.font.style = FontAttribBold
progmssg6.font.style = FontAttribBold
progmssg7.font.style = FontAttribBold
Peter Rousseau
Experiment 2:
I rem'd out the locking/unlocking code.
I created two buttons on the form and placed the locking code in one, unlocking
in the other
I pressed the locking button, checked the tables and they were all locked
I pressed the unlocking button, checked all the tables and all were UNlocked!
I reactivated the code in the open/close methods, saved the form and rebooted all
the machines
The damn thing worked!
Question - is it possible that a variable etc., gets held onto in memory and the
program doesn't represent the actual code and variables? I've found that in
another DOS program, I have to restart the program to clear memory or registers -
I have to admit that I don't know much about hardware/software architecture to
know what I am talking about.
Peter Rousseau
David Portwood wrote:
> I agree with Mark, use an alias when locking and unlocking your tables. In
> fact, use an alias with any table operations because this will help you keep
> your app independent of whatever the working directory might be.
>
> Btw, it should be a rare occasion that you need table locks. Record locks
> are usually sufficient. Why do you need these table locks, if you don't mind
> me asking?
I am importing data from another application to update these tables.
Peter R
David Portwood
I suppose you are using add() to update the tables, but what about using a
tcursor to update the tables record by record? I'm sure add() is faster, but
it requires table locks. If you update record by record, you don't need any
table locks.
If you update record by record there is an additional possibility, if you so
choose: the update can be done using a timer so it takes place invisibly in
the background. In so doing, there will be no need to pause or stop current
operations to perform the update. This may not be necessary in your
situation, but it is nice to keep in mind.
With table locks, you have to consider the possibility that you might not
get the required locks. This leads you to program a loop asking the user if
he wants to retry. Ok, this is easily codeable, but IMO it looks bad. And
what happens if the user tries a couple of times without getting the
required locks and then gives up?
"Peter Rousseau" <Pe...@solutionsbyknight.com> wrote in message
news:413F33FB...@solutionsbyknight.com...
Peter Rousseau
Hi david:
You are totally right. I also know there is a potential for interruptions (eg,
power los) which will result in inaccurate data if(when) it happens. The reason
it is being done this way is because I designed it a couple years ago-there are
about 7 proceses that the data goes through to get molded into shape and
includes queries-when I was just learning about databases and when I redo it, it
will be a massive project so I keep putting it off. I know, I know...
I've ben thinking of one way to deal with the possibility of interruptions is to
put the new data into a table and have a tcursor update record by record. When a
record is confirmed to be updated then the tcursor would delete it from the
table. Then when the form starts it looks to see if there are any records and if
there are then it knows the update hasn't been finished and would carry on from
where it left off.
I also have about 4-5 child table to deal with. I remember one time I saw Dennis
(I think) write that he rathers not to depend on referential integrity and uses
tcursors instead. So, I have a lot of work to do.
Oh yeah, I'm using a lot of queries, not add() to do the updates.
Peter R
Steve Urbach
>You are totally right. I also know there is a potential for interruptions (eg,
>power los) which will result in inaccurate data if(when) it happens.
If data integrity is an issue, now is the time to get a good quality
UPS with AVR. Prices have come way down.
1) be sure to have sufficient backup time to allow the process to
complete. Better yet, break the process Data into smaller segments
(maybe scan loop. Flag the data processed, not delete processed data
to KISS) so a segment completes fairly quickly so the system could
shut down between segments.
2) if a server is involved, the server needs enough UPS time for its
part of the task.
3) Remember to put UPS on all hubs/switches in the data path <G>
4) LCD panels draw way less than their CRT counter part allowing
smaller UPS size for the same amount of time.
Steve U
Bertil Isberg
Peter
<<
Question - is it possible that a variable etc., gets held onto in memory and
the
program doesn't represent the actual code and variables?
>>
BUT, I have seen cases - when working with Paradox 5 - where code in a
library is not the code running because library was opened in a form when
changes were made to the code.