Re: Accessing a paradox table from a C# application...

On Mar 9, 10:08 am, "Larry DiGiovanni" <nos...@xxxxxxxxxx> wrote:
<jason.p...@xxxxxxxxx> wrote:
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

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

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

.

Relevant Pages

  • Re: MS SQL Server/ODBC package for Python
    ... Running your benchmark, I ran into a couple of interesting points. ... I changed the query to ... If adodbapi avoids this (which we'll also integrate into mxODBC 2.1), then this would explain the differences you see. ... ODBC driver doesn't provide proper size information - each ...
    (comp.lang.python)
  • Re: Accessing a paradox table from a C# application...
    ... I would get a copy of Paradox and play around with restructuring the table and indexes and see what happens to query speed. ... There are several threads on the optimal way to set up a network. ... SELECT TOP 1000 * FROM ModelSer ...
    (comp.databases.paradox)
  • Re: ODBC driver manager mangles delimited column names
    ... Thanks Robert, I'm beginning to think you are right. ... I've just finished running some more tests with the trace logging turned on for the ODBC driver manager. ... This is what I get in the log for the automatically generated query: ...
    (microsoft.public.data.odbc)
  • RE: Need to be able segregate units run in excel sheet using time.
    ... It may be possible - using the timestamp as I ... you add the time stamp at the time the query was run. ... > I don't see a way around this, unless there is more to the database than I ... > the type of situation I describe above better than you can in Excel. ...
    (microsoft.public.excel.programming)
  • Re: Number of Records
    ... Paradox query process but seem to remember it can generate a lot of traffic ... > Diamond Software Group ... > Diamond Sports Gems ...
    (comp.databases.paradox)