Does anyone have a solution for the GPV that comes when the Table
Lookup tab is pressed in the Table Create, Restructure and Info
Structure dialogs? My Paradox 10.0.0.990 installation started doing
this yesterday after letting me look at and alter Table Lookups for
years.

The other machines on our office network can still restructure Table
Lookups across the network.

Yesterday I had a GPV during a scan in which I was changing a large
table. The target table, which was newly created and started empty got
so corrupted that the table repair utility wouldn't fix it and failed
itself. I guess this damaged the registry somehow.

Other people with the same problem have suggested a re-installation
does not work.

Any ideas, short of a disk reformat?

Fred Z

Hi,

I thought I'd share my experiences, in case they were relevant. When I used
Pdox 8, opening a table with a broken Lookup link would *always* GPV, and
there was *no* way to fix it. The broken link *had* to be repaired before
the table could be opened, or even repaired. This meant reconstructing --
which Paradox hardcodes into the table structure when it creates the link.

Now I use Pdox 11.0.0.411, and tables fail gracefully when they have a
broken lookup link. They throw up an error which gives the user the chance
to sever the link; when this is chosen, the table opens normally and
without GPV. (Pdox 8 threw up the same error box, but would GPV before the
table could be fixed or opened.)

The gurus around here advise that you handroll your own lookup to prevent
this problem. Bear in mind that the *actual path* is hardcoded, not the
alias. So if you install your app on a client computer, you must duplicate
this path exactly (including the drive letter IIRC.) Same goes for the
built-in referential integrity.

If you use Pdox as a personal workstation database, as I do, the built-in
lookup is too tempting to resist. For my money, it is useable *only* on
versions late enough to allow it to fail gracefully -- evidently only Pdox
11.

Now, as to recovering data: Try to reconstruct the exact path structure
present when the lookup was created, from drive letter to file name. That
should let you repair, then restructure, the table.


Jim Hargan

On 20 Nov 2006 06:42:48 -0800, Fred Z wrote:

On Mon, 20 Nov 2006 13:21:47 -0500, Jim Hargan wrote:

This should read:
This meant reconstructing the original path -- which Paradox hardcodes
into the table structure when it creates the link.

Fred Z wrote:
The previous response by Jim Hargan is accurate. Also note that, even
though this causes a GPV in various versions of Paradox, it does /not/
affect the data in your table. In other words, you might experience errors
but the data should all still be there, awaiting the problem to be fixed.

----
ChimneySweep(R): Fast(!) table repair at a click of the mouse!
http://www.sundialservices.com

Jim, thanks. I lost no data. Your reply gives me some ideas for fixes.

The weird thing is the GPV comes even when I try to create a new table,
define one field, then click the table lookup tab. So it can't be my
old table. I must have corrupted the registry somehow.

Anyway, sounds like I better upgrade my Paradox and my Windows.

Fred Z

On 20 Nov 2006 11:13:02 -0800, Fred Z wrote:

If you are running Win98 or WinME, IMO these opsystems cannot be secured or
stabilized and should be replaced.

If you are running WinXP, a System Restore will roll back your registry in
a harmless and fully reversible manner. Click "Start", then "Help", then
"Undo changes to your computer with System Restore" (found under "Pick a
task").

I posted a 12 step program for stabilizing XP at
http://soho.harganonline.com/survive/12step/12step.htm
that has always worked for me.

A hard drive failure is always possible -- a hard drive is the ultimate in
moving parts. If the drive platter is damaged where Paradox's program
resides, the program might not execute properly. Steve Gibson's Spinrite
will repair any media problem with any drive platter, as well as add years
to a drive's life. Worth the $89 price at:
http://www.grc.com/sr/spinrite.htm

I would do all of this before upgrading from Pdox 10 to the nearly
identical Pdox 11.


HTH,

Jim Hargan

There is info on this and ways to make table lookups functional in my
Database Basics paper on our Paradox resources page. Link in my signature.

Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
Offices in the United States and Germany
Providing solutions to health care, business, governments and non-profits
since 1982

Fred Z wrote:
I'm replying to my own post because I seem to have fixed the problem.
I'm not sure how, but I did.

I discovered I had backup tables with bad referential integrity, by
which I mean child tables with entries for which there was no
corresponding parent entry. Possibly came about from GPVs part way
through processes, I dunno. I also had huge cascading data issues as my
backups used table copy, which seems to copy the RI.

I deleted all RI and secondary indexes from backup tables everywhere,
(after making two separate backup DVDs with all the data on each, good,
bad or ugly) deleted RI and the odd VAL file from current tables and
rebuilt RIs as needed.

All of a sudden the table lookup was back.

Hope this helps someone else.

Fred Z

Thanks for the feedback

--
Bertil Isberg - CTECH
Paradox buglist:
online: http://hem.bredband.net/bertilisberg/

"Fred Z" <fredzcalgary (AT) hotmail (DOT) com> skrev i meddelandet
news:1166211162.966310.309450 (AT) 73g2000cwn (DOT) googlegroups.com...