Title: Message
Depends the size of the tables and the spec of the machine running on. A reasonably sizeable table on a <500MHz machine will take minutes - tens of minutes to rebuild, which probably isn't good on start up.
 
A better way would be to run a scheduler and have it rebuild in the middle of the night.
 
There is a table rebuilding util called TUtil which rebuilds Paradox tables. Cant remember the URL but a google search should find it.
-----Original Message-----
From: Mark Howard [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 6 September 2001 10:41
To: Multiple recipients of list delphi
Subject: Re: [DUG]: SQL Poser

That's an interesting suggestion. But some questions:
Is this recommended practice?
Does it slow down startup significantly (26 tables)
What code do you use to see if you have exclusive use of table?
What do you use to rebuild the indexes - will DBIRestructure do it?
Mark
 
----- Original Message -----
Sent: Thursday, September 06, 2001 9:39 AM
Subject: Re: [DUG]: SQL Poser

It pays to rebuild the indexes automatically on startup of the first instance. ie. if you can get exclusive use of the table when you start rebuild the indexes. This way any crashes, power offs etc are automatically recovered from. This seems to required more often with paradox then dbase. dbase has a slightly more complicated problem with indexes being detached but this does not happen very often.
 
Maurice
----- Original Message -----
Sent: Thursday, September 06, 2001 8:06 AM
Subject: Re: [DUG]: SQL Poser

Neven
 
Thanks!  Rebuilt the Customer table and all was well.
Wonder how long it would have taken me to get to that solution.  I thought screwed indexes always resulted in error messages.  This sort of symptom is much more worrisome (resulting in people not getting invoiced).
 
Appreciate your help.
 
Mark
----- Original Message -----
Sent: Wednesday, September 05, 2001 5:20 PM
Subject: Re: [DUG]: SQL Poser

Mark
 
SQL looks fine I'd say your indexes are screwed
 
Neven
----- Original Message -----
Sent: Wednesday, September 05, 2001 5:15 PM
Subject: [DUG]: SQL Poser

Hi
 
This question relates to a Paradox database and a three table query: the main table is Dockets the other two (Forest and Customer) merely provide a look up to get Forest and Customer names.
 
Trouble is as follows:
I can select from Dockets and return the correct number of dockets when I'm looking up either the Forest or the Customer but not both.  But this ONLY happens for one specific customer.
 
The tests I have done, with the results, follow.
 
Can any one suggest what is happening here?  I hope I have given enough information.
 
ANY suggestions will be appreciated.
 
TIA
 
Mark
 
select D.DocketNo,
 D.ForCode,
 D.CustCode
from  Dockets D
 where  D.DocketDate > '07/01/2001'
 and  D.CustCode = "HBERT"
 and  D.ForCode = "MOCO"
 
Returns dockets  
   55895
   55899
 
Now lookup Customer name
select D.DocketNo,
 D.CustCode,
 C.CustName
from  Dockets D,
 Customer C
 where  D.DocketDate > '07/01/2001'
 and  D.CustCode = C.CustCode
 and  D.CustCode = "HBERT"
 
Returns dockets  
   55895
   55899
 
Now lookup Forest name instead
select D.DocketNo,
 D.ForCode,
 F.ForName
from  Dockets D,
 Forest F
 where  D.DocketDate > '07/01/2001'
 and  D.ForCode = F.ForCode
 and  D.ForCode = "MOCO"
 
Returns dockets  .
   .
   55895
   55899
   .
   .
   .
 
Now try to lookup both Customer AND Forest names
select D.DocketNo,
 D.ForCode,
 F.ForName,
 D.CustCode,
 C.CustName
from  Dockets D,
 Forest F,
 Customer C
 where  D.DocketDate > '07/01/2001'
 and  D.ForCode = F.ForCode
 and  D.CustCode = C.CustCode
 and  D.ForCode = "MOCO"
 
BOTH DOCKETS MISSING
 

select D.DocketNo,
 D.ForCode,
 F.ForName,
 D.CustCode,
 C.CustName
from  Dockets D,
 Forest F,
 Customer C
 where  D.DocketDate > '07/01/2001'
 and  D.ForCode = F.ForCode
 and  D.CustCode = C.CustCode
 and  D.CustCode = "HBERT"
 
BOTH DOCKETS MISSING
 

Reply via email to