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]

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

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