Hi everyone,
First off, I am very new to using Paradox tables, so I am stumped as
to how I should go about addressing these problems.

Anyway, I have a C# application that needs to access a Paradox
database over a network (through an ODBC connection). I have
successfully been able to do this in the past, but when I tried to
deploy a change this morning, the performance was intolerable and even
crashed my application. At first, I thought that I simply couldn't
connect, but it turns out that the queries are not performing well.

For example, if I run the following query:
SELECT TOP 1 * FROM ModelSer
or even:
SELECT TOP 1000 * FROM ModelSer

the query runs fairly well (the latter is slower, obviously).

Now, the table is (supposed) to be set to have the model, serial, and
timestamp set as the primary key. This would lead me to expect that
if I try this query:
SELECT TOP 1 * FROM ModelSer ORDER BY Timestamp

....that it would run fairly quickly. However, that wasn't the case.
If I used a test database locally, it took me 2 minutes to get a
response. At first, I noticed that I didn't have BDE installed. I
installed it and noticed no performance difference. However, if I
delete the .PX file corresponding to the table, the performance is
much better. When I try to restructure it with the primary keys, the
performance sucks again.

I have doing this kind of thing for about 6 months, but I can't quite
get a handle on what is going on. Any advice would be greatly
appreciated.

Sincerely,
Jason Pell

This group is about the Application Paradox, more than the table structure.

And from your description the issue is your coding, which isn't in the
Paradox language, or the BDE perhaps. Maybe even the ODBC driver. Which
version of which company's odbc driver are you using; they are NOT all
equal.

Not to snub you or anything, but I'm guessing a group for C# or possibly the
BDE may get you a quicker and better answer.

Others here may have knowledge to help you with the exact issue. However,
just wanted you to be aware that the people who hang out here are here for
the Application rather than the table structure.

--
---------------------------------------------------------
Tony McGuire

<jason.pell (AT) gmail (DOT) com> wrote:

If the PK is in the order you provided, then ordering by timestamp wouldn't
be helped by the PK, which is ordered by other stuff first.

What ODBC driver are you using (vendor and version)?
How much faster is the query if you strip off the PX?
How many rows are in ModelSer?
What are you using to restructure the table to add the PK back?

--
Larry DiGiovanni

On Mar 9, 10:08 am, "Larry DiGiovanni" <nos... (AT) nospam (DOT) com> wrote:
Thank you for all of your replies.

First, I have no control over the network because we are contracting
with large corporation and have to use whatever network they are
using. The ODBC driver that I am using is the Microsoft Paradox
Driver. This is where I discovered something...in my test
environment, I was actually using Paradox 5.0. Unknown to me, they
had upgraded to Paradox 7.0. Apparently, the Microsoft Paradox Driver
doesn't support 7.0. I have since explored the Merant(?) ODBC driver
and have made some progress there. Does this seem to be the correct
route to take? I am much more familiar with MySQL and MSSQL, and we
are trying to slowly move away from Paradox so that we are consistent
in with DBMS's.

To answer some more questions, there are about 300,000 rows in
ModelSer on my test environment. I'm not sure how many are on the
actual machine (I'm actually taking a day off from work today, so I'm
not in the office), but it is probably about the same. When I strip
off the PX driver, it takes probably 20 seconds to run the query.
When the PX table is there it takes about 140 seconds. To be
specific, this is the query where I order by Timestamp. To
restructure the table, I am using Borland Database Desktop 7.

Finally, I apologize if this is the incorrect newsgroup, but as I
mentioned earlier, I have little experience with Paradox, so this
seemed to be a good fit as to where to get help. Thanks again,
everyone!

Sincerely,
Jason Pell

FYI switching from Paradox 5.0 to Paradox 7.0 does NOT automatically update
the table levels. It is perfectly possibly to be running Paradox 7 but still
using Paradox 5 tables. You can in fact have a mix of tables with several
different versions in one Paradox database. I think this is different from
example MS Access where you probably update the whole database when you open
and save it in a later version

That is correct BUT it my testing shows that it IS possible to read also
level 7 tables. However performance is very bad, so this is probably your
issue.


The general idea is that the Merant driver is better, but have in mind that
most of us here doesn't use ODBC to access our Paradox tables.

You should be able to see which level the table has.

Anders