Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 8 of 8 total |
Still problem on locate (incremental search) Urgent! |
Mon, May 8 2006 11:40 AM | Permanent Link |
"Stefano Monterisi" | 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. |
Mon, May 8 2006 3:00 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Tue, May 9 2006 6:16 AM | Permanent Link |
"Stefano Monterisi" | 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 > > |
Tue, May 9 2006 4:20 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Wed, May 10 2006 4:14 AM | Permanent Link |
"Stefano Monterisi" | 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 > > |
Wed, May 10 2006 6:10 AM | Permanent Link |
"Stefano Monterisi" | 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 |
Wed, May 10 2006 3:40 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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. >> I'll see what I can do. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, May 11 2006 6:26 AM | Permanent Link |
"Stefano Monterisi" | > 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 > > |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |