Article

From:
To:
Ann Lynnworth
Subject:
Re: Building index issue
Newsgroup:
hreftools.public.rubicon.support

Re: Building index issue

That would be a very expensive solution to the problem, probably running 
several thousand dollars with Delphi upgrade and multiple third-party 
component upgrades required.

How about Plan B?
William
"Ann Lynnworth" wrote in message news:cdp2349@WendzelNNTPdAnonymous...
Which Delphi compiler were you using with Rubicon v2? It would have been a non-Unicode compiler, something prior to Delphi 2009. That is the biggest reason for a difference.
For many reasons, the current Rubicon v4 supports Delphi 2010+. We did a lot of optimization work from Rubicon v3. to v4, dozens of small changes, most of which related to the consequences of UnicodeString.
I am not sure about DBISAM but most vendors improved their UnicodeString feature set and performance in the years since D2009 came out. Even if you are working with English or "Latin1" text, the data may still be going through multiple conversions between AnsiString and UnicodeString, depending on what is happening within the component access layer. If the makers of DBISAM say their current performance is better than it was at D2009, that would be important.
I would recommend adding event handlers for OnMinIndex and OnMaxIndex.
Generally I would also say to use an integer field, not a string field containing digits, for the primary key.
When there are big gaps in primary key sequence, the optimized bitmap that Rubicon uses to represent the distribution of words in your data ..... becomes not to optimized. When you last worked with Rubicon 2, was the distribution of numbers similar in terms of gaps ?
Bottom line, I'm asking you whether there is any possibility you can use a newer Delphi and thus a newer DBISAM and Rubicon.
Ann
FYI: Phrase searches are enclosed in either single or double quotes
 
 
Originally created by
Tamarack Associates
Thu, 28 Mar 2024 21:31:52 UTC
Copyright © 2009-2024
HREF Tools Corp.