Strange query error

"missing answer table"

That's definitely the problem - you left off the "answer: :priv:answer.db"
clause (or wherever you want it to go). Once I added that - my only error
is I don't have your tablenames available.
 >> Stay informed about: Strange query error 

Joseph,

Bertil recently posted about a similar problem. If you use the 'Check' option,
you cause an Order By and a Sort, IIRC. This might run into the limits of
the table size. Does it work with 'CheckPlus'?

What is your default BDE block size (of your answer table)?
How many rows are in :priv:Whs1.db?


Jim Moseley
 >> Stay informed about: Strange query error 

"Jim Giner" wrote in message

> first off - there is no answer table mentioned. Did you 'type' this up
> manually?

I did not type it manually. Copied and pasted from file.
 >> Stay informed about: Strange query error 

"Jim Giner" wrote in message

> "missing answer table"
>
> That's definitely the problem - you left off the "answer: :priv:answer.db"
> clause (or wherever you want it to go). Once I added that - my only error
> is I don't have your tablenames available.

That seems to have fixed the error I was getting when run interactively. You
can add an answer table below the opening Query statement. I am still
getting the other error.
 >> Stay informed about: Strange query error 

"Jim Moseley" wrote in message

>
> Joseph,
>
> Bertil recently posted about a similar problem. If you use the 'Check'
> option,
> you cause an Order By and a Sort, IIRC. This might run into the limits of
> the table size. Does it work with 'CheckPlus'?

I was not able to get the query to work with CheckPlus, either with all
fields changed from Check to CheckPlus or else just the JobItem fields.

> What is your default BDE block size (of your answer table)?

I do not get an answer table, but the default block size of the BDE is 4096.

> How many rows are in :priv:Whs1.db?

That table has 115 rows and JobItem.DB has 1050412 records. The issue is
that if Whs1.db has only a single JobKey in all of its rows, the query will
run successfully. When a second JobKey is added, then the error occurs. I do
not believe table size is an issue here because this query will only use a
small number of the JobItem records, at most a few hundred.

I am now getting more interactive information since I added the answer
table. "Corrupt file - other than header." Table: JobItem.db
File:JobItem.px. However, the PX file is not corrupt. It has been rebuilt
with both Chimney Sweep and alternately with TUtility. A TUtility verify
reports a BTree error, and Chimney Sweep reports no errors. I do not believe
this table is corrupted because the data is heavily used elsewhere and there
is no erroneous data reported. I think this is related to this query.

Thanks,
Joe
 >> Stay informed about: Strange query error 

Okay, maybe I need to take that back on the table not being corrupted. I am
doing some further querying and possibly we are running into "corruption".
However, it is not corruption that is sorted out by either of the repair
utitlities. Because the indexing is not working, I am thinking that this is
because there is a string as part of the index. Would anyone have any hard
evidence that if we went to long integers instead of strings, this would
clear up? I remember something from a few years ago on strings in keys, but
there was something about it possibly being limited to secondary indexes.

Many thanks and happy thanksgiving,
Joe
 >> Stay informed about: Strange query error 

What about making this a 2 query process.

Query #1
Using a job key or keys,
simply do a one table query from jobitems,
and rename answer table to temp table.

Then query #2
Do your 2 table query that you do now...
but do not link 3 times into jobItems that has 1M plus records,
but link to your temp table that was created in Query #1.

Perhaps this could avoid errors that surface when you have multiple job
keys.

Good luck
Robert Wiltshire
 >> Stay informed about: Strange query error 

> the default block size of the BDE is 4096.

> JobItem.DB has 1050412 records.

> I do not believe table size is an issue

you're kidding, right?

how big is that million-record table?.. why do you still have that tiny
block size?.. and most important, do you realize what happens to the size of
an answer table with an outer-join, or something like "not" in the
parameters?

so, do two things.. do the repair to rule out corruption, and make a bigger
table to rule out size.. then get back to us..

--
Steven Green - Myrtle Beach, South Carolina USA

http://www.OasisTradingPost.com

Oasis Trading Post
- Collectibles and Memorabilia
- Vintage and Custom Lego Creations

Diamond Software Group
- Paradox Support & Sales

Diamond Sports Gems
- Sports Memorabilia and Trading Cards
 >> Stay informed about: Strange query error 

"Robert Wiltshire" wrote in message

>
> What about making this a 2 query process.

Great suggestion. I did that. It seems we are finding that still not all
information from the job table is pulled. Wish I had better information on
what is causing this error. Thanks for the suggestion, --Joe

> Query #1
> Using a job key or keys,
> simply do a one table query from jobitems,
> and rename answer table to temp table.
>
> Then query #2
> Do your 2 table query that you do now...
> but do not link 3 times into jobItems that has 1M plus records,
> but link to your temp table that was created in Query #1.
>
> Perhaps this could avoid errors that surface when you have multiple job
> keys.
>
> Good luck
> Robert Wiltshire
>
>
>
>
>
 >> Stay informed about: Strange query error 

"Steven Green" wrote in message

>> the default block size of the BDE is 4096.
>
>> JobItem.DB has 1050412 records.
>
>> I do not believe table size is an issue
>
> you're kidding, right?

Well, I was not trying to be kidding! 8^D

I have read a number of reports of Paradox tables with over a million
records. This table has only a few fields and only the item number is
non-numeric. The table is currently

> how big is that million-record table?

The DB file is 114 MB.

> .. why do you still have that tiny block size?

Although the BDE block size is 4K, this table is 16K (we changed it a couple
of years ago). It is only 10% full according to the size calculations I
have.

Fields: 14
Record Size: 112 bytes
Block Size: 16K
Records per Block: 146
Table Version: 7

> .. and most important, do you realize what happens to the size of an
> answer table with an outer-join, or something like "not" in the
> parameters?

I do understand how these types of criteria work. There are no "not"
parameters. Nearly all of these records have a match, so the outer join
will be identical to the inner join 99% of the time.

> so, do two things.. do the repair to rule out corruption, and make a
> bigger table to rule out size.. then get back to us..

The table has been rebuilt in both Chimney Sweep and TUtility. CS reports no
errors or issues. TU keeps reporting a BTree error.

I am not really spotting the error. My best lead is that the alpha field in
the primary key is some type of Paradox limitation.

Any other suggestions? Thanks either way! --Joe

>
> --
> Steven Green - Myrtle Beach, South Carolina USA
>
> http://www.OasisTradingPost.com
>
> Oasis Trading Post
> - Collectibles and Memorabilia
> - Vintage and Custom Lego Creations
>
> Diamond Software Group
> - Paradox Support & Sales
>
> Diamond Sports Gems
> - Sports Memorabilia and Trading Cards
>
 >> Stay informed about: Strange query error