Hi Tim,
I had problems on release 3.x on locate in incremental search (please see my
old posts locate with Dbisam 3.30)
Now, with Dbisam 4.22 I have the same problem in incremental search
(devexpress cxlookups).
What I have to change in the source for solve the problem?
Urgent!, please.
(I have noted now the problem but the application is already in customers
hands)

Thanks,
Stefano Monterisi


<Stefano,
<
<< I use this system for simulate an incremental search, but in this case it
<don't works because it trim the space between 'TIM' and 'AND';
<I have already deleted the line "RightTrimString(@TempFiledBuffer,#32)" in
<TdataCursor.InternlaPutField, but without success; >>

<That's where the modification takes place since Locate uses internal
TFields
<to populate the record buffer used for the search.  Are you sure that
<recompiled everything okay ?

<< Attention, I use [loPartialKey,loCaseInsensitive] as locate parameters;
<If I delete loCaseInsensitive parameter, all work ok! But I need
<loCaseInsensitive option. >>

<Did you make any other modifications to the DBISAM code ?  There shouldn't
<be any difference between using loCaseInsensitive and not using it - the
internal field assignment still uses the InternalPutField method and handles
<the spaces in the same manner.

Stefano,

<< I had problems on release 3.x on locate in incremental search (please see
my old posts locate with Dbisam 3.30) Now, with Dbisam 4.22 I have the same
problem in incremental search (devexpress cxlookups). What I have to change
in the source for solve the problem? >>

Change this line in dbisamen.pas:

procedure TDataCursor.InternalPutField(FieldDefinition: pFieldDefinition;
                                      RecordBuffer: PChar; FieldBuffer:
PChar;
                                      WriteToExpressions: Boolean;
BlobEmpty: Boolean);
begin
  with FieldDefinition^ do
     begin
     if (ExpressionField and (not WriteToExpressions)) or
        (FieldNum=RECORDID_FIELD_NUM) or
        (FieldNum=RECORDHASH_FIELD_NUM) then
        Exit;
     if (FieldBuffer <> nil) then
        begin
        case DataType of
           TYPE_ZSTRING:
              begin
              FillChar((RecordBuffer+Offset+FLDCHG_DATA)^,DataSize,#0);
              StrLCopy((RecordBuffer+Offset+FLDCHG_DATA),FieldBuffer,(DataSize-1));
              if (SubType <> SUBTYPE_FIXED) then
                 RightTrimString((RecordBuffer+Offset+FLDCHG_DATA),#32);
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,
how are you?
Please explain:
I must CHANGE the line or COMMENT the line?
I the meantime, I have already commented two lines:
//  if (SubType <> SUBTYPE_FIXED) then
//      RightTrimString((RecordBuffer+Offset+FLDCHG_DATA),#32);
It's ok?
There are repercussions in the normal storage of data in all other cases?
Strange, why other programmer don't have the same need?
In the next release please find a solution in the code without manually
changes (I don't like to modify Dbisam sources).
Thanks in advance for support.

P.s.: If you remember I was the first to invoke cached updates; Now I use
still Kbmmemtable for simulate memory tables to involve into cached updates;
I consider to use native cached updates with release 5 of dbisam, but I have
found that the approch is'nt the best. true?

Stefano Monterisi



"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> ha scritto nel
messaggio news:F396C6BA-D815-4F5C-A061-241218F68BBA@news.elevatesoft.com...
> Stefano,
>
> << I had problems on release 3.x on locate in incremental search (please
> see my old posts locate with Dbisam 3.30) Now, with Dbisam 4.22 I have the
> same problem in incremental search (devexpress cxlookups). What I have to
> change in the source for solve the problem? >>
>
> Change this line in dbisamen.pas:
>
> procedure TDataCursor.InternalPutField(FieldDefinition: pFieldDefinition;
>                                       RecordBuffer: PChar; FieldBuffer:
> PChar;
>                                       WriteToExpressions: Boolean;
> BlobEmpty: Boolean);
> begin
>   with FieldDefinition^ do
>      begin
>      if (ExpressionField and (not WriteToExpressions)) or
>         (FieldNum=RECORDID_FIELD_NUM) or
>         (FieldNum=RECORDHASH_FIELD_NUM) then
>         Exit;
>      if (FieldBuffer <> nil) then
>         begin
>         case DataType of
>            TYPE_ZSTRING:
>               begin
>               FillChar((RecordBuffer+Offset+FLDCHG_DATA)^,DataSize,#0);
>
> StrLCopy((RecordBuffer+Offset+FLDCHG_DATA),FieldBuffer,(DataSize-1));
>               if (SubType <> SUBTYPE_FIXED) then
>                  RightTrimString((RecordBuffer+Offset+FLDCHG_DATA),#32);
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Stefano,

<< how are you? >>

Very well, thank you.

<< I must CHANGE the line or COMMENT the line? >>

You must comment out the line if you don't want the trimming.

<< I the meantime, I have already commented two lines:
//  if (SubType <> SUBTYPE_FIXED) then
//      RightTrimString((RecordBuffer+Offset+FLDCHG_DATA),#32);
It's ok? >>

Yes.

<< There are repercussions in the normal storage of data in all other cases?
>>

Yes, data will not be right-trimmed when stored.

<< Strange, why other programmer don't have the same need? >>

They probably are using the ftFixedChar field type to avoid right-trimming
of the field.

<< In the next release please find a solution in the code without manually
changes (I don't like to modify Dbisam sources). >>

Use the ftFixedChar field type.

<< P.s.: If you remember I was the first to invoke cached updates; Now I use
still Kbmmemtable for simulate memory tables to involve into cached updates;
I consider to use native cached updates with release 5 of dbisam, but I have
found that the approch is'nt the best. true?>>

Well, the cached updates in DBISAM work just fine.  They are not as complete
as TClientDataSet and the ability to use SQL statements to re-update a
joined result set, but they work for single tables just fine.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,
why the problem of trimming is present when I use DevExpress lookups and is
not present with Infopower lookups?
Thanks.
(For cached updates I must tell you my opinion, ma now isn't right time, I
have too much job to do; We will discuss in future)

Stefano Monterisi

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> ha scritto nel
messaggio news:51824819-BAB4-42C7-8407-CF14F7EFCD39@news.elevatesoft.com...
> Stefano,
>
> << how are you? >>
>
> Very well, thank you.
>
> << I must CHANGE the line or COMMENT the line? >>
>
> You must comment out the line if you don't want the trimming.
>
> << I the meantime, I have already commented two lines:
> //  if (SubType <> SUBTYPE_FIXED) then
> //      RightTrimString((RecordBuffer+Offset+FLDCHG_DATA),#32);
> It's ok? >>
>
> Yes.
>
> << There are repercussions in the normal storage of data in all other
> cases?
> >>
>
> Yes, data will not be right-trimmed when stored.
>
> << Strange, why other programmer don't have the same need? >>
>
> They probably are using the ftFixedChar field type to avoid right-trimming
> of the field.
>
> << In the next release please find a solution in the code without manually
> changes (I don't like to modify Dbisam sources). >>
>
> Use the ftFixedChar field type.
>
> << P.s.: If you remember I was the first to invoke cached updates; Now I
> use still Kbmmemtable for simulate memory tables to involve into cached
> updates; I consider to use native cached updates with release 5 of dbisam,
> but I have found that the approch is'nt the best. true?>>
>
> Well, the cached updates in DBISAM work just fine.  They are not as
> complete as TClientDataSet and the ability to use SQL statements to
> re-update a joined result set, but they work for single tables just fine.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Tim,
I have tried:
Infopower use its "locate" methods with findkey etc...; It use standard
dataset Locate only for show the records, if necessary.
Devexpress use dataset Locate (grid mode=True);
Now, I need  both search all text I have entered (with space at end because
I am searching particular case) and trimming when I store the data (if not
fixed type, like correctly dbisam does).
Can we have the 2 things (in the next releases) without modify the sources?
It's no possibile that if you have "New york" and "New york city" you cannot
search (incrementally) the second, without modify the Dbisam trimming data
logic.
I have reason or not?
Please solve the problem, Tim.
I have always the good italian wine ready for you

Thanks a lot,

Stefano Monterisi

Stefano,

< I have tried:
Infopower use its "locate" methods with findkey etc...; It use standard
dataset Locate only for show the records, if necessary.  Devexpress use
dataset Locate (grid mode=True); Now, I need  both search all text I have
entered (with space at end because I am searching particular case) and
trimming when I store the data (if not fixed type, like correctly dbisam
does).

Can we have the 2 things (in the next releases) without modify the sources?
It's no possibile that if you have "New york" and "New york city" you cannot
search (incrementally) the second, without modify the Dbisam trimming data
logic. >>

I'll see what I can do.

--
Tim Young
Elevate Software
www.elevatesoft.com

> I'll see what I can do.

Hi, Tim,
Thank a lot for the availability...

Good Job,
Stefano Monterisi


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> ha scritto nel
messaggio news:799A33D1-7436-49CF-B488-B32B1C489A34@news.elevatesoft.com...
> Stefano,
>
> < I have tried:
> Infopower use its "locate" methods with findkey etc...; It use standard
> dataset Locate only for show the records, if necessary.  Devexpress use
> dataset Locate (grid mode=True); Now, I need  both search all text I have
> entered (with space at end because I am searching particular case) and
> trimming when I store the data (if not fixed type, like correctly dbisam
> does).
>
> Can we have the 2 things (in the next releases) without modify the
> sources? It's no possibile that if you have "New york" and "New york city"
> you cannot search (incrementally) the second, without modify the Dbisam
> trimming data logic. >>
>
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>