Subject Re: [IBO] IBO 4.9.5 released (release candidate beta)
Author m. Th.
Jason Wharton wrote:
> I produced a new version of the installer for 4.9.6.
> I'd appreciate any feedback on how it works on your system.
>
> Thanks,
> Jason Wharton
>
>
>
The DevExpress library is *NOT* working. You *didn't* include any of the
fixes which I've sent to you. After so many months (4 - four, to be more
correct) since I started to post publicly the fixes, the product is in
the same state.

IOW you still cannot manage to control your *own* product, Jason. And
this raises some serious questions about your ability to move the
product forward. And this is very amazing because you said that this is
your full time job now. 4 (four) months to put an 'AnsiString'
declaration? I found it in 10 (ten) minutes.

And the situation isn't good at all for IBO, you know:

http://wings-of-wind.com/2009/08/27/rad-studio-2010-community-pulse-the-day-after-part-1/

FIBPlus has two times bigger market share - not counting that Zeos and
IBX has also a greater market share than IBO. Also, now as you perhaps
know, DBX (which has three times bigger share) got a Firebird driver...

...Also, using lookup fields in TIBO layer *DOESN'T* work - the
following is still present: (the fix is at the end, I'll post it once
more again for your sake)


---------------------------
Debugger Exception Notification
---------------------------
Project Test.exe raised exception class EIBO_ISCError with message 'ISC
ERROR CODE:335544569

ISC ERROR MESSAGE:
Dynamic SQL Error
SQL error code = -502
Invalid cursor declaration
Statement already has a cursor 1 assigned

STATEMENT:
TIBOInternalDataset: "<TApplication>.dmoPostCode.ibtPrefs.IBOqribtPrefs."

'.
---------------------------
Break Continue Help
---------------------------



---8<------8<------8<------8<------8<------8<------8<------8<---

(Reposted from my message dated on 25/6/2009 called "[IBO] "Statement
has already assigned 1 cursor" error - The fix")

In IB_Components.Pas we have

function TIB_BDataset.SysLookupKeyForBufferFields(
ANodeRef: TIB_NodeRef ):
boolean;
...

errcode := isc_dsql_set_cursor_name( @status,
@FSeekCursor,
pbyte(IntToStr(cardinal(FSeekCursor)) +
CursorName ),
0 );
...

the above isc_dsql_set_cursor_name call is around of line no 34625 (but
is possible to be different in your sources).

The problem is that (at least) IntToStr returns an Unicode string which
can have #0. So we must change to:

cName:=IntToStr(cardinal(FSeekCursor))+ CursorName;

errcode := isc_dsql_set_cursor_name( @status,
@FSeekCursor,
pbyte(cName),
0 );


...where cName is a local AnsiString (IOW cName: AnsiString)

---8<------8<------8<------8<------8<------8<------8<------8<------8<------8<---

For the Bookmark engine, search for my post called '[IBO] GetBookmark -
The Fix' (posted on 20/7/2009) - Copy / Pasted here in verbatim:

WRT to the 'GetBookmark' thread, there is a bug in Bookmark engine in
TIBO layer.

In short, the following existing code...

function TIBODataSet.GetBookmark: TBookmark;
var
B: AnsiString;
begin
B := GetBookmarkStr;
Result := nil;
if B <> '' then
begin
Result := AllocMem( BookmarkSize );
{$IFDEF IBO_VCL2009_OR_GREATER}
Move( pointer( B )^, Result[0], BookmarkSize ); //<--- AV here!
{$ELSE}
Move( pointer( B )^, Result^, BookmarkSize );
{$ENDIF}
end;
end;


...throws an AV because Result is an array and it should properly
initialized.

So, the fix looks like:

function TIBODataSet.GetBookmark: TBookmark;
var
B: AnsiString;
begin
B := GetBookmarkStr;
if B <> '' then
begin
{$IFDEF IBO_VCL2009_OR_GREATER}
SetLength(Result, BookmarkSize);
Move( pointer( B )^, Result[0], BookmarkSize );
{$ELSE}
Result := AllocMem( BookmarkSize );
Move( pointer( B )^, Result^, BookmarkSize );
{$ENDIF}
end
else
Result:=nil;
end;


...I changed a little bit the logic because having a 'Result=nil' and
after this a SetLength can be 'odd' for the compiler sometimes...


Sorry for being a little harsh but istm that is needed, you must be much more focused on the community feedback, otherwise you're doomed.

HTH,

m. Th.