Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 3 of 3 total |
I'm converting DBISAM 3 to DXE (Unicode) |
Fri, Sep 16 2011 11:12 AM | Permanent Link |
Rolf Frei eicom GmbH | I have converted DBISAM 3 to DXE and it works now very well so far I have
done tests, but I encountered one strange thing: Any TParam.AsString := 'XY' gets set as unicode and not as AnsiString per default anymore. This was a ugly break in D2010, which was a big fault in my opinion by Embarcadero. This will break so much of code out in the world, as I can't believe they have realy changed that. The problem is now with any DB-System who must use AnsiString (BDE,DBISAM,..). As a result of that, all exisiting code must be changed to AsAnsiString to get parameters working correct. TParam.AsString was in D2009 still AnsiStrings and that should be still the default. It' s so bad thing that Embarcaderohas changed this in D2010+! As of this problem I try to change the dbismatb.GetParamData so it will automaticly convert the widestring ParamData to AnsiString. As a result of this change, my version of this routine looks now so: procedure GetParamData(Param: TParam; Buffer: Pointer); var s: AnsiString; begin with Param do begin if (DataType in [ftBlob..ftTypedBinary]) or ((DataType in [ftString,ftFixedChar]) and (Length(VarToStr(Value)) > MAX_FIELD_SIZE)) then begin with TQueryBlobParam(Buffer^) do begin BlobBuffer:=TRecordBuffer(PAnsiChar(VarToStr(Value))); BlobLength:=Length(VarToStr(Value)); end; end else begin GetData(Buffer); {--- New code to convert the paramdata to ansistring if it is widestring ---} if (DataType in [ftWideString,ftFixedWideChar]) then begin s := AnsiString(PChar(Buffer)); StrCopy(PAnsiChar(Buffer), PAnsiChar(S)); end; {--- End of Change ---} end; end; end; As DBISAM doesn't support native Unicode, I think it will be correct that any widestring params should be convertet to AnsiString here. It works perfectly as far I can see, but I'm not sure if there may be a problem with it, which I can't see yet, as I have missing or to less DBISAM internals knowledge. What do you think about this? Will be my code fine this way? Regards Rolf [Team Elevate] |
Mon, Sep 19 2011 11:25 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Rolf,
<< As DBISAM doesn't support native Unicode, I think it will be correct that any widestring params should be convertet to AnsiString here. >> Yes, that is correct. <<It works perfectly as far I can see, but I'm not sure if there may be a problem with it, which I can't see yet, as I have missing or to less DBISAM internals knowledge. What do you think about this? Will be my code fine this way? >> Yes, it will be fine. In general, DBISAM 4.x simply forces all strings to AnsiString with a hard cast when getting/setting data from/to the engine, so a similar technique will work fine with DBISAM 3.x. Also, if you're recompiling the 3.x source code under a Unicode-enabled Delphi, then you need to make sure that all of the engine units are using AnsiString instead of String for general string declarations. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Sep 20 2011 7:11 PM | Permanent Link |
Rolf Frei eicom GmbH | Hi Tim
Thank you for your answer. As I already wrote, I have done that already and it works perfectly so far. All Properties like DataBaseName, SessionName, TableName and some others, I did keept to String, as else the Property editors didn't work. I can't see a problem with this as it seems to work perfectly. There were some problems with bookmarks, but I have all of them solved and any CompareBookmarkt and such routines work now correct. Also any Buffer Declaration were changed from PChar to TRecordBuffer (PByte) and anything I need in my applications seems to work. Now I'm able to go forward with my unicode conversion of my application so I'm able to use XE for the future. Regards Rolf [Team Elevate] "Tim Young [Elevate Software]" schrieb im Newsbeitrag news:1B730FA6-A1A0-432C-88CC-5957CB277FCB@news.elevatesoft.com... Rolf, << As DBISAM doesn't support native Unicode, I think it will be correct that any widestring params should be convertet to AnsiString here. >> Yes, that is correct. <<It works perfectly as far I can see, but I'm not sure if there may be a problem with it, which I can't see yet, as I have missing or to less DBISAM internals knowledge. What do you think about this? Will be my code fine this way? >> Yes, it will be fine. In general, DBISAM 4.x simply forces all strings to AnsiString with a hard cast when getting/setting data from/to the engine, so a similar technique will work fine with DBISAM 3.x. Also, if you're recompiling the 3.x source code under a Unicode-enabled Delphi, then you need to make sure that all of the engine units are using AnsiString instead of String for general string declarations. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |