TechTips: Corrupt tables aren't always -there-

TechTips: Corrupt tables aren't always -there-

Post by Sundial Service » Tue, 07 May 2002 23:17:25



"Corrupt table, other than header" ... "Index out of date" ... yet when
you scan the table, it's fine!  What gives?

Remember:  tables can be related to one another, through table-lookups,
referential integrity links and so on.  

Also, a form or report data-model can involve many tables.

Any one of these could be the culprit.  The message you are seeing could
be downright misleading.

----------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

Quote:> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R):  Release 4.0 is here!!
> http://www.sundialservices.com/products/chimneysweep

 
 
 

TechTips: Corrupt tables aren't always -there-

Post by Laurie McIntos » Wed, 08 May 2002 06:49:48


Hi Mike,

You know, it's for this very reason that I NEVER set up referential
integrity or lookup tables in a table's structure. I'd be interested to
know... does ANYONE use these features when building anything other than a
quick and dirty enquiry database?

---=L


> "Corrupt table, other than header" ... "Index out of date" ... yet when
> you scan the table, it's fine!  What gives?

> Remember:  tables can be related to one another, through table-lookups,
> referential integrity links and so on.

> Also, a form or report data-model can involve many tables.

> Any one of these could be the culprit.  The message you are seeing could
> be downright misleading.

> ----------------------------------------------------------------
> Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

> > Fast(!), automatic table-repair with two clicks of the mouse!
> > ChimneySweep(R):  Release 4.0 is here!!
> > http://www.sundialservices.com/products/chimneysweep


 
 
 

TechTips: Corrupt tables aren't always -there-

Post by Sundial Service » Wed, 08 May 2002 07:16:01


As-designed, Referential Integrity is unfortunately "just about
useless."  Table lookups are generally okay, as long as the reference
string used to specify the identity of the lookup table is always-valid
(e.g. through a known-good alias name).  But I tend to employ program
code to do these things.


> You know, it's for this very reason that I NEVER set up referential
> integrity or lookup tables in a table's structure. I'd be interested to
> know... does ANYONE use these features when building anything other than a
> quick and dirty enquiry database?

----------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

Quote:> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R):  Release 4.0 is here!!
> http://www.sundialservices.com/products/chimneysweep

 
 
 

TechTips: Corrupt tables aren't always -there-

Post by Dennis Santor » Wed, 08 May 2002 07:00:38


I use lookup but I make sure to do it so there are no path references (see my
Database Basics paper on our Paradox resources page for more on that). But
never RI.

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


> Hi Mike,

> You know, it's for this very reason that I NEVER set up referential
> integrity or lookup tables in a table's structure. I'd be interested to
> know... does ANYONE use these features when building anything other than a
> quick and dirty enquiry database?

> ---=L



> > "Corrupt table, other than header" ... "Index out of date" ... yet when
> > you scan the table, it's fine!  What gives?

> > Remember:  tables can be related to one another, through table-lookups,
> > referential integrity links and so on.

> > Also, a form or report data-model can involve many tables.

> > Any one of these could be the culprit.  The message you are seeing could
> > be downright misleading.

> > ----------------------------------------------------------------
> > Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

> > > Fast(!), automatic table-repair with two clicks of the mouse!
> > > ChimneySweep(R):  Release 4.0 is here!!
> > > http://www.sundialservices.com/products/chimneysweep

 
 
 

TechTips: Corrupt tables aren't always -there-

Post by Steven Gree » Wed, 08 May 2002 07:23:36



> You know, it's for this very reason that I NEVER set up referential
> integrity or lookup tables in a table's structure. I'd be interested to
> know... does ANYONE use these features when building anything other than a
> quick and dirty enquiry database?

RI is useless.. but lookup tables are an essential validation tool.. the
validation process can be handled via standard lookup process and/or via
code.. but the tables themselves are essential either way..

--

Steve Green - Diamond Software Group, Inc - Waldorf Maryland USA
Corel CTech Paradox - http://www.diamondsg.com - Support/Downloads/Links
---------------------------------------------------------------------------------

Do you need a Sanity Check? http://www.diamondsg.com/sanity.htm
Upgrade/Downgrade versions? http://www.diamondsg.com/upgrade.htm
-------------------------------------------------------------------------

 
 
 

TechTips: Corrupt tables aren't always -there-

Post by Laurie McIntos » Wed, 08 May 2002 11:52:43


Okay people... what do you use lookup FOR (the table field property, I
mean)? I mean, if you're rolling your own lookup screens, what are the
advantages?

---=L

> I use lookup but I make sure to do it so there are no path references (see
my
> Database Basics paper on our Paradox resources page for more on that). But
> never RI.

> 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


> > Hi Mike,

> > You know, it's for this very reason that I NEVER set up referential
> > integrity or lookup tables in a table's structure. I'd be interested to
> > know... does ANYONE use these features when building anything other than
a
> > quick and dirty enquiry database?

> > ---=L



> > > "Corrupt table, other than header" ... "Index out of date" ... yet
when
> > > you scan the table, it's fine!  What gives?

> > > Remember:  tables can be related to one another, through
table-lookups,
> > > referential integrity links and so on.

> > > Also, a form or report data-model can involve many tables.

> > > Any one of these could be the culprit.  The message you are seeing
could
> > > be downright misleading.

> > > ----------------------------------------------------------------
> > > Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

> > > > Fast(!), automatic table-repair with two clicks of the mouse!
> > > > ChimneySweep(R):  Release 4.0 is here!!
> > > > http://www.sundialservices.com/products/chimneysweep

 
 
 

TechTips: Corrupt tables aren't always -there-

Post by Dennis Santor » Wed, 08 May 2002 07:23:54


You can't actually get it to use an alias name. You can get it to use a path or
no path. With path is only portable to exact replicas of the path. No path is
fully portable but that means the lookup is in the same directory as the table
doing the looking and you have to do the setup right even with that setup not to
get a path hard coded.

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


> As-designed, Referential Integrity is unfortunately "just about
> useless."  Table lookups are generally okay, as long as the reference
> string used to specify the identity of the lookup table is always-valid
> (e.g. through a known-good alias name).  But I tend to employ program
> code to do these things.


> > You know, it's for this very reason that I NEVER set up referential
> > integrity or lookup tables in a table's structure. I'd be interested to
> > know... does ANYONE use these features when building anything other than a
> > quick and dirty enquiry database?

> ----------------------------------------------------------------
> Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

> > Fast(!), automatic table-repair with two clicks of the mouse!
> > ChimneySweep(R):  Release 4.0 is here!!
> > http://www.sundialservices.com/products/chimneysweep

 
 
 

TechTips: Corrupt tables aren't always -there-

Post by Dennis Santor » Wed, 08 May 2002 17:16:40


Mostly data entry control.

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


> Okay people... what do you use lookup FOR (the table field property, I
> mean)? I mean, if you're rolling your own lookup screens, what are the
> advantages?

> ---=L


> > I use lookup but I make sure to do it so there are no path references (see
> my
> > Database Basics paper on our Paradox resources page for more on that). But
> > never RI.

> > 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


> > > Hi Mike,

> > > You know, it's for this very reason that I NEVER set up referential
> > > integrity or lookup tables in a table's structure. I'd be interested to
> > > know... does ANYONE use these features when building anything other than
> a
> > > quick and dirty enquiry database?

> > > ---=L



> > > > "Corrupt table, other than header" ... "Index out of date" ... yet
> when
> > > > you scan the table, it's fine!  What gives?

> > > > Remember:  tables can be related to one another, through
> table-lookups,
> > > > referential integrity links and so on.

> > > > Also, a form or report data-model can involve many tables.

> > > > Any one of these could be the culprit.  The message you are seeing
> could
> > > > be downright misleading.

> > > > ----------------------------------------------------------------
> > > > Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

> > > > > Fast(!), automatic table-repair with two clicks of the mouse!
> > > > > ChimneySweep(R):  Release 4.0 is here!!
> > > > > http://www.sundialservices.com/products/chimneysweep

 
 
 

TechTips: Corrupt tables aren't always -there-

Post by Tom Krie » Wed, 08 May 2002 18:12:51


Rolling your own lookups with tCursor qLocates and/or custom lookup forms
gives control and flexibility. No need to worry what Paradox is doing.

--
Tom Krieg


> Okay people... what do you use lookup FOR (the table field property, I
> mean)? I mean, if you're rolling your own lookup screens, what are the
> advantages?

> ---=L


> > I use lookup but I make sure to do it so there are no path references
(see
> my
> > Database Basics paper on our Paradox resources page for more on that).
But
> > never RI.

> > 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


> > > Hi Mike,

> > > You know, it's for this very reason that I NEVER set up referential
> > > integrity or lookup tables in a table's structure. I'd be interested
to
> > > know... does ANYONE use these features when building anything other
than
> a
> > > quick and dirty enquiry database?

> > > ---=L



> > > > "Corrupt table, other than header" ... "Index out of date" ... yet
> when
> > > > you scan the table, it's fine!  What gives?

> > > > Remember:  tables can be related to one another, through
> table-lookups,
> > > > referential integrity links and so on.

> > > > Also, a form or report data-model can involve many tables.

> > > > Any one of these could be the culprit.  The message you are seeing
> could
> > > > be downright misleading.

> > > > ----------------------------------------------------------------
> > > > Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259

> > > > > Fast(!), automatic table-repair with two clicks of the mouse!
> > > > > ChimneySweep(R):  Release 4.0 is here!!
> > > > > http://www.sundialservices.com/products/chimneysweep

 
 
 

TechTips: Corrupt tables aren't always -there-

Post by Laurie McIntos » Thu, 09 May 2002 08:21:32


Quote:> Rolling your own lookups with tCursor qLocates and/or custom lookup forms
> gives control and flexibility. No need to worry what Paradox is doing.

Well, that's my point... so why set up Lookup in the table itself?

---=L

 
 
 

TechTips: Corrupt tables aren't always -there-

Post by Laurie McIntos » Thu, 09 May 2002 08:23:59


Quote:> Mostly data entry control.

Sorry Den... would you mind elaborating? I mean, when I set up a table that
requires a lookup, I just link the two in the data model... display a lookup
screen, pass the selected value back, post it, and viola... what am I
missing? What extra data entry control is provided by hardwiring the lookup
table?

Regards,

---=L

 
 
 

TechTips: Corrupt tables aren't always -there-

Post by Michael Israel, M.D » Thu, 09 May 2002 09:49:16


Flexibility is not alway desirable.  For example, A Zip code look-up table.
Zipcode, City,  State are the fields (Zipcode is the look-up field).  Type in
Zip and City State appear.  This requires that all cities have zip codes.

> > Rolling your own lookups with tCursor qLocates and/or custom lookup forms
> > gives control and flexibility. No need to worry what Paradox is doing.

> Well, that's my point... so why set up Lookup in the table itself?

> ---=L

 
 
 

TechTips: Corrupt tables aren't always -there-

Post by Steve Urba » Thu, 09 May 2002 10:49:25


On Wed, 08 May 2002 00:49:16 GMT, "Michael Israel, M.D."


>Flexibility is not alway desirable.  For example, A Zip code look-up table.
>Zipcode, City,  State are the fields (Zipcode is the look-up field).  Type in
>Zip and City State appear.  This requires that all cities have zip codes.

And some Zip codes have multiple cities. The only hard rule is that
they are in the same state. I let the user overide the City.
I use a "zx" field for the plus4 or plus 6 additional parts OR
international postal codes. That way they don't need to exist in my US
Zip lookup.

Steve U


>> > Rolling your own lookups with tCursor qLocates and/or custom lookup forms
>> > gives control and flexibility. No need to worry what Paradox is doing.

>> Well, that's my point... so why set up Lookup in the table itself?

>> ---=L

,        _
,       | \                           MKA: Steve Urbach
,       |  )erek                      No JUNK in my email please

,  / / /                            
 
 
 

TechTips: Corrupt tables aren't always -there-

Post by Dennis Santor » Thu, 09 May 2002 18:43:49


Well, if a value is put in that does not belong in some way or other you get a
key violation. Also, you have to write code for multifield fill. All I have to
do is move one value. I'm of the school that if I can use default Paradox
behavior, why write code. And there is no downside to this behavior unlike the
RI issues. But I do often intervene in the lookup process and use a custom form.
But if a user wants to just be able to type a value in (for example, they often
get to know zip codes so why do a lookup) then they type it in and the town and
state show up automagically with no code needed.

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


> > Mostly data entry control.

> Sorry Den... would you mind elaborating? I mean, when I set up a table that
> requires a lookup, I just link the two in the data model... display a lookup
> screen, pass the selected value back, post it, and viola... what am I
> missing? What extra data entry control is provided by hardwiring the lookup
> table?

> Regards,

> ---=L

 
 
 

TechTips: Corrupt tables aren't always -there-

Post by Steven Gree » Thu, 09 May 2002 20:14:49



> I wasn't aware that a zip code can have more than one city.  Attached is a keyed
> Paradox table of zip codes from an old "Paradox Secrets" file (cicra 1993)

yes, zip codes can cross city lines

yes, zip codes can change

and don't you know how many zip codes (and area codes, for that matter) have been
added in the last nine years? you've got to keep updating that data..

--

Steve Green - Diamond Software Group, Inc - Waldorf Maryland USA
Corel CTech Paradox - http://www.diamondsg.com - Support/Downloads/Links
---------------------------------------------------------------------------------
Do you need a Sanity Check? http://www.diamondsg.com/sanity.htm
Upgrade/Downgrade versions? http://www.diamondsg.com/upgrade.htm
-------------------------------------------------------------------------