Set Paradox Table Locations with RDC

Hello

I'm using Delphi with the 8.5 RCD component to create a standand alone CR application. I want to offer a function which allows users to quickly set the database location of all the tables in a report to where I know the data will be. The code is easy enough to do (iterating through all the tables and then subreport tables) buts its outrageously slow! On a report with about 25 tables  it takes 2 minutes! i.e. 4 seconds for each iteration in this code snippet:

    for i := 1 to rpt.database.tables.count do
    begin
     s  :=FindPath('htdb') + rpt.database.tables.item[i].name + '.db';
     rpt.database.tables.item[i].location := s;
    end;

If you do it manually in the Designer from the in built popup menus then once you commit the changes it does seem to take a few seconds, so I was wondering whether this overhead / function call is happening for EACH table I set the location for? Is there a way around this? I tried the alternative, 'SetTableLocation' method (rpt.database.tables.item[i].settablelocation (s,'','')) but that always returns an error of  'Invalid Pointer' :-(

Any ideas?

Paul
tomsieAsked:
Who is Participating?
 
moduloCommented:
PAQed, with points refunded (250)

modulo
Community Support Moderator
0
 
mlmccCommented:
What is the horsepower of the machines?  Can you try the code on some faster machines and see if it runs any faster or if it is a connection through Crystal issue.  25 Tables seems like an awful lot of tables to connect to.

Are you sure it is in that code and not just the time it takes to generate the report?

One thought.  Does this call always return the same value - FindPath('htdb') -?  If so put it outside the loop as

strPath = FindPath('htdb')

Then you can use strPath instead of the call.

mlmcc
0
 
tomsieAuthor Commented:
Hmm..I replied to this but my post seems to have been lost. To summarise: its not FindPath() that has the overhead though I agree its silly to call it in a loop); its definitely the RDC. I suspect its calling the same routine that it uses in its own environment for setting database locations over and over again. I don't think 25 tables is an awful lot and we've been using this report for years and setting its location when printing via our main app using CRPE32 API calls. Its takes a split second there.

Perhaps this is a design oversight by Seagate. My PC is 633 Mhz and about 320Mb RAM. Not great but not awful either.
0
 
mlmccCommented:
I suspect the RDC wil be slower because it will translate your calls into API calls.  The RDC is designed to make our lives easier not necessarily run reports faster.

Are these subreports?  

Has the database grown appreciably?

Is the network overloaded?

mlmcc
0
 
tomsieAuthor Commented:
Running (previewing) the report is not the problem; that is fast regardless of the (local) database size. The problem is just setting the table locations before the report is previewed. I think this is just a design flaw in the RDC since is you set the database locations manually (right click  , Set Database Location) then then native interface for doing it is very fast. Doing it in code the performance gets exponentially worse for "each" table location assignment as the number of tables in a report increases, i.e. if only 2 tables then a few millisecond for "each" assignment, if 17 then 5 seconds for each. No doubt the RDC as iterating through all the tables performing some checks each time it sets a location. The really curious thing though is that that my report does have 2 subreports (each with 4 tables) and these zip through in no time at all, i.e. faster than a standalone report with 4 tables.

I think I will just have to live with it a put a progress bar indicator in the project somewhere. Thanks for the help.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.