how to copy live paradox tables

#31

Quote:

This table would identify EVERYONE CURRENTLY ONLINE. As a function of
your applications opening and closing, these entries are added or deleted
from this common table.

nope.. if the app aborts, crashes, etc.. the entry is left open, just like
the lock file (g)

--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales

Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Sports Memorabilia and Trading Cards
"Rodney Wise" <NSpamPlease_rodney1 (AT) bellsouth (DOT) net> wrote

Quote:

I believe the best way to deal with this is to cause ALL users to
automatically make an entry into a common table which is located in the
"Net" directory (Logged in or Logged out). This table would identify
EVERYONE CURRENTLY ONLINE. As a function of your applications opening and
closing, these entries are added or deleted from this common table.

By tracking who is Online... you can establish rather it is safe to lock
the table directory and begin copying the data tables or not. You could
even go as far as to design your application to automatically send a
message to those who are Online, stating that they need to quit their work
within the next 5 minutes.... etc.

By placing this logging table in the Net Dir, you are assured that
everyone can see it and use it. It wouldn't take much effort to cause
your apps to automatically log users on and off of this table.

Of course, if a user would somehow quit their Paradox app in an unorthodox
manner (Ctrl-Alt-Delete), they may not get properly logged out of the
table.... you will have to devise a reliable method to handle this.

I use this logging method and find I can use the information for a lot of
other uses too. You can include users time in and time out.... client IP
addresses, etc., etc....

--
...
`·.¸¸.·´¯`·.¸¸.·´¯`·-> rodney

#32

"Steven Green" wrote:

Quote:

nope.. if the app aborts, crashes, etc.. the entry is left open, just like
the lock file (g)

======================

As I indicated, one would have to write code to handle this potential issue.

One way to do this is to have all clients periodically update a timestamp
field in the Logon table (that I mentioned in the previous post) via an Opal
timer (say, every 3 or 5 minutes). This could be handled by your
applications Hidden Desktop Form which most apps have to handle custom
menus.

Now, anyone listed in the Login Table indicating that they are "logged on",
should never have a timestamp which exceeds the difference between now() and
the set timer period. If someone's timestamp does exceed the timer
period, then you know that they are simply no longer logged in (ie; they
"crashed" out of the program).

Upon discovering this error, you would then have your application write the
error to an error log and now that false or miss leading login record can be
safely deleted from the login table.

If the error log file continues to report this error message being produced
by the same person... (ie; you have a problem child) then you need to have a
talk with them.

But this would let you know if its safe to delete any BDE LCK files that
might be hanging around and if its safe to rename the data directory and
copy your data tables.

While this sounds complicated... it really isn't. I believe using a table
in the NET Dir to track who is on line and who isn't... is an important and
handy thing to have for all networked applications. Well worth the time and
effort to devise and implement.

--
....
`·.¸¸.·´¯`·.¸¸.·´¯`·-> rodney

#33

John,

"abend" means "abnormal ending".

When Paradox / BDE shuts down normally, it removes any occurrences of *.lck
created by the user during the session.

Otherwise they are left in place.

When Paradox / BDE starts up, it looks for *.lck files and if there are any
left over, it refuses to start (with a confusing message).

If the *.lck files are in place because of a current user, they cannot be
deleted by anyone with the OS, including the current user, until Paradox is
shut down.

If they have been left from a previous session, they can be.

BTW, your comment elsewhere about not using Paradox puzzles me. If you have
an application running, your organisation must have Paradox somewhere.

If you run Paradox, properly configured for the application, you can easily
see which users (identified by their network login) have Paradox running.

Given that some users typically leave their PCs running all night, you would
need to do something about them - presumably kill their PCs remotely.

"John Ligda" <jligda (AT) offithall (DOT) com> wrote

Quote:

Robert,
You idea sounds like a good safeguard and far better than just copying all
files and hoping noone is using the application because of the late hour.

I have one question however.

You can find out if anyone is using a copy by searching for files like
*.lck.

If there are none, you know no-one is using the database using the Borland

Database Engine.

If there are any *.lck files, and you can delete them, they have been left

over through the BDE being abended.

How do I know the difference between a .lck file 'left over through the
BDE
being abended' and an actual user lock? I'm not sure what you mean by
'BDE
being abended'. Can you clarify?

Thank you.

John

#34

John,

Paradox costs about $150. It is all you need as a "support tool".

Paradox includes a tool that lets you check which users are currently
connected.

See elsewhere about *.lck files left lying around.

If a user has Paradox running, with active *.lck files, you cannot rename
the directory that contains them.

So your step 2 will last all night.

And thus step 3 cannot happen.

BUT:

If all you are trying to do is get a backup, using the normal server backup
software processes will do.

*** This presumably includes remote disconnection of any PCs left connected
to the server ***.

Paradox saves everything to disk immediately during editing, so there would
be a possibility of a user being disconnected having left one record (of one
or more tables) in limbo / incomplete.

Probably no more significant that the risk of a user losing edits to a major
Word document if disconnected during network backups.

If you have to restore from the backup, you would encounter the *.lck files
captured at the time, but you can simply delete them at restore time.

BTW - a good zip utility would be another way - simply make a zip of
YourRenamedDataBase to YourDataCCYYMMDD. Typically, Paradox databases are
reduced to about 10% of full size with zips.

"John Ligda" <jligda (AT) offithall (DOT) com> wrote

Quote:

Thanks for the responses everyone. I just read them today and I
appreciate
the thoughtfulness you all give to the forum.

First off, we are not going to buy any paradox support tools so whatever
we do it will be at the OS level.

Here is what I am thinking after reading the post.
1) Schedule a nightly job at a time when it is very VERY unlikeley anyone
is in the system.
2) Search the directory for .LCK files until there are none
3)rename the directory
4) copy the files
3)rename the directory back to the original name

Does this sound about right? Are there any reasons a .lck file might
hange
around even if noone is using the application?

Again, thanks for all your help.

Cheers

john

"john ligda" <jligda (AT) offithall (DOT) com> wrote:

Hello, I am very new to paradox databases but have some familiarity with
Oracle and MS SQL rdbms concepts. I would like to learn how to safely
copy
paradox data files while the database is operatonal. Is this possible?

Im used to some sort of admin tool which hides the complexity involved
in
preserving a valid database state. I have no idea if such a tool exists
for paradox databases. To add to the confusion, I will not be allowed
to
touch the production tables myself. I will instead, be prviding a safe
solution
to the administrator so that he can provide me with consistant refreshes
of the production tables. We want to do this nightly.

Our first attempt was to simply copy the data directory with Windows OS
commands.
He delivered a directory of .DB, .TV, .PX files. I was able to extract
data from the .DB tables but have no idea if the data transaction
integrity
is preserved. In fact, on one table there is a violation of the primary
key on the very last record. I suspect the copy is corrupt because of the
way it was copied. But honestly i have no idea. Can anyone direct me
to
a resource where I can read about basic administration for paradox
databases?
Specifically how to safely copy/mirror/replicate source systems without
affecting daily operations of end users.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

how to copy live paradox tables

comp.databases.paradox comp.databases.paradox

Re: how to copy live paradox tables - 09-06-2006 , 02:04 PM

Re: how to copy live paradox tables - 09-06-2006 , 02:57 PM

Re: how to copy live paradox tables - 09-06-2006 , 05:51 PM

Re: how to copy live paradox tables - 09-06-2006 , 06:13 PM