Very Computer

It works fine until it tries to run a query on a table that was used
as output from the previous query, then it gags. Any ideas how to
solve this?

Thanks,
Linda

Quote:> I'm struggling to produce a script (PXWIN8) that has multiple queries
> that must be performed in sequence.

> It works fine until it tries to run a query on a table that was used
> as output from the previous query, then it gags. Any ideas how to
> solve this?

--KC

Quote:> I'm struggling to produce a script (PXWIN8) that has multiple queries
> that must be performed in sequence.

> It works fine until it tries to run a query on a table that was used
> as output from the previous query, then it gags. Any ideas how to
> solve this?

> Thanks,
> Linda

Quote:>> I'm struggling to produce a script (PXWIN8) that has multiple queries
>> that must be performed in sequence.

>> It works fine until it tries to run a query on a table that was used
>> as output from the previous query, then it gags. Any ideas how to
>> solve this?

Steve White

For _all reporting tasks in any of my programs, and many menu-commands
too, I use a table driven sequencer where "QUERY" is merely another
opcode.  The typical sequence for a report is:
        CREATE  the tables needed
        DIALOG  to display an input form to obtain parameters
        QUERY  
        QUERY  
        ...
        IFEMPTY :PRIV:ANSWER, There are no results to display!
        SORT
        PINDEX  make a primary index for the data model
        REPORT  run the report
        END

One system I built had, at one time, over 100 different report sequences
and one compact bit of sequencer-code (ReportRabbit) ran them all.

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

Quote:> I assume you've tried a breakpoint in the code to see where it is
> faltering. Are you releasing the newly created tables in your code?
> Some example of the code that is failing would be helpful.

I came to the conclusion that because the (many) queries are still "open"
and the table is still "open" it behaves in the same manner as interactive
Paradox, i.e. it won't let you run a query on table that is open in the
workspace. The trick is that I can't find a way to "close" the table or
queries so that I can continue.

This comes about because I need to add data to a single table that is reused
in each query. The sad thing is that I can happily do this in the DOS
version!

thanks for the help,
linda mc

Quote:> > I assume you've tried a breakpoint in the code to see where it is
> > faltering. Are you releasing the newly created tables in your code?
> > Some example of the code that is failing would be helpful.

> Actually it fails because the table is open and I can't find a way to
> "release the newly created table". Is there any way to release the
variable?

> I came to the conclusion that because the (many) queries are still "open"
> and the table is still "open" it behaves in the same manner as interactive
> Paradox, i.e. it won't let you run a query on table that is open in the
> workspace. The trick is that I can't find a way to "close" the table or
> queries so that I can continue.

> This comes about because I need to add data to a single table that is
reused
> in each query. The sad thing is that I can happily do this in the DOS
> version!

> thanks for the help,
> linda mc

Quote:>Actually it fails because the table is open and I can't find a way to
>"release the newly created table". Is there any way to release the variable?

Pasted queries affect the paradox / BDE environment differently than code
queries. Sorry I can't be more specific.

If using pasted in queries, try using code line queries instead. Like
qvar.appendtable...
qvar.setcriteria...  

Also, things can get ugly if querying tables with very long keyed alpha fields.
Review the table structures.

Good luck.

Randy Prentice

Hera are some problems with the query type in ObejctPAL

FIXED IN P9 SP1
When query.enumFieldStruct() is used, the table specified in the query will
not be released in a proper way, not even when the form is closed . Try to
Restructure the table and you'll get the message: Table in Use.

FIXED IN P7 Win95
Whenever I delete a set of records from within a form, using a delete query,
PDox permanently leaves a table lock on that table. No other user will then
have write access to that table. As soon as the first user logs out, the
lock goes away.

This behavior is absolutely reproducible and happens on more than one delete
query.

My comment: Description is too simple. More was needed for the problem to
occur.

STILL OPEN
Query.isQueryValid() leaves a lock on the tables used in the query.

STILL OPEN
When q.setAnswerFieldOrder() is applied to a query variable, the Alias used
in the Query will stay open afterwards. Alias Manager will report  Database
is open and Cannot be modified.

--
Bertil Isberg CTECH
read  the newsgroup:  corel.wpoffice.paradox-faq
for Frequently Asked Questions
---------------------------------------------------

Jean Friedberg

Quote:> I would simply add that if Paradox wasn't able to perform multiple
> sequential queries, I would be out business.  My application, is in
> daily use in over a dozen manufacturing plants, and many, many
> pushbuttons run use sequential queries to generate the final
> underlying table for reports and forms.  I have never had a problem.
> I also generally don't bother to change the query variable from query
> to query.  Works every time.  Works in Versions 7,8,9, & 10.

> Steve White