| Subject | Re: [IBO] Plans for IBO Help file ....? |
|---|---|
| Author | Bjørge Sæther |
| Post date | 2003-03-07T12:16:24Z |
I'm not used to needing a "Getting Started Guide", and if it *is* necessary,
it should be bundled with the product.
An introduction to IBO should start with something like: "To be happy with
IBO, you need to think differently from what you're used to. Some of the
differences stems from IB architecture "pecualiarities", while the rest of
it has to do with a somewhat different philosophy on working with database
applications.
I'd like to know this *before* deciding to go for IBO.
I'm not going to spend more time telling you people about my feels for IBO.
I don't believe I'm gonna be a project contributor, as my spent $395
somewhat contradicts to the feeling of being part of a "volunteer
developer's community". If I'm still using IBO a few months from now, I'll
surely gonna be trying to help other developers through this forum.
from ibobjects homepage:
<snip>
Some Benefits of IB Objects
* Switch from BDE to IBO in seconds with no loss of functionality!
[snipped some *true* statements]
* 2 to 5 times overall performance increase is typical
</snip>
...in my part of the world, you're normally *very* careful with such
statements. I know marketing is different on the other side of the Atlantic
Ocean, and I should probably have recognized the "slight exaggerations".
A tip:
I suggest that in the future, IBO should either: a) Use some kind of IBO-sql
syntax (as SQL parsing is obviously a large problem), or b) Let the client
app process SQL *as is*, whenever possible. The only problems I've
encountered similar to IBO's "don't understand that syntax", is DataSnap
providers failing to create correct SQL for inserts / updates. Those who
want a simple, bi-directional query component should not need to satisy
IBO's demand for "valid SQL". Take a next step up from TIB_Cursor and create
the simplest possible bi-directional version.
First of all, components that doesn't allow you to write "SELECT * FROM.."
needs improvement.
Secondly, if they for some reason can't figure out how to "correct" the
(perfectly valid) "SELECT * FROM.." syntax, they should at least generate an
exception telling you that it "can't figure out what key to use for table
XXX" instead of a "Token unknown: ','" in some obscured SQL generated under
the hood.
And, while at it, remove 90% of the error message texts (you'll have quite
a lot of it while learning yourself IBO) so that the *real* error message is
visible.
Well, here's my contribution to the IBO community:
function ErrorMessageStringFilter(const S: string): string;
const
IBERR_PREFIX = 'ISC ERROR MESSAGE:';
IB_DYN_SQL_ERR = 'Dynamic SQL Error'#13#10'SQL error code = ';
IB_STATEMENT = #13#10'STATEMENT:';
var
APos: integer;
begin
APos:=Pos(IBERR_PREFIX, S);
if APos > 0 then
result:=Trim(Copy(S, APos+Length(IBERR_PREFIX)+1, Length(S)))
else
result:=S;
APos:=Pos(IB_DYN_SQL_ERR, result);
if APos > 0 then begin
delete(result, APos, Length(IB_DYN_SQL_ERR));
APos:=Pos(#13#10, result);
if APos > 0 then
delete(result, 1, APos+1);
end;
APos:=Pos(IB_STATEMENT, result);
if APos > 0 then
Delete(Result, APos, Length(result)-APos+1);
result:=trim(result);
end;
--
Regards,
Bj�rge S�ther
bjorge@haha_itte.no
"Svein Erling Tysvaer" <svein.erling.tysvaer@...> skrev i
melding news:5.1.0.14.0.20030307113227.02b6b8d0@[158.36.132.22]...
it should be bundled with the product.
An introduction to IBO should start with something like: "To be happy with
IBO, you need to think differently from what you're used to. Some of the
differences stems from IB architecture "pecualiarities", while the rest of
it has to do with a somewhat different philosophy on working with database
applications.
I'd like to know this *before* deciding to go for IBO.
I'm not going to spend more time telling you people about my feels for IBO.
I don't believe I'm gonna be a project contributor, as my spent $395
somewhat contradicts to the feeling of being part of a "volunteer
developer's community". If I'm still using IBO a few months from now, I'll
surely gonna be trying to help other developers through this forum.
from ibobjects homepage:
<snip>
Some Benefits of IB Objects
* Switch from BDE to IBO in seconds with no loss of functionality!
[snipped some *true* statements]
* 2 to 5 times overall performance increase is typical
</snip>
...in my part of the world, you're normally *very* careful with such
statements. I know marketing is different on the other side of the Atlantic
Ocean, and I should probably have recognized the "slight exaggerations".
A tip:
I suggest that in the future, IBO should either: a) Use some kind of IBO-sql
syntax (as SQL parsing is obviously a large problem), or b) Let the client
app process SQL *as is*, whenever possible. The only problems I've
encountered similar to IBO's "don't understand that syntax", is DataSnap
providers failing to create correct SQL for inserts / updates. Those who
want a simple, bi-directional query component should not need to satisy
IBO's demand for "valid SQL". Take a next step up from TIB_Cursor and create
the simplest possible bi-directional version.
First of all, components that doesn't allow you to write "SELECT * FROM.."
needs improvement.
Secondly, if they for some reason can't figure out how to "correct" the
(perfectly valid) "SELECT * FROM.." syntax, they should at least generate an
exception telling you that it "can't figure out what key to use for table
XXX" instead of a "Token unknown: ','" in some obscured SQL generated under
the hood.
And, while at it, remove 90% of the error message texts (you'll have quite
a lot of it while learning yourself IBO) so that the *real* error message is
visible.
Well, here's my contribution to the IBO community:
function ErrorMessageStringFilter(const S: string): string;
const
IBERR_PREFIX = 'ISC ERROR MESSAGE:';
IB_DYN_SQL_ERR = 'Dynamic SQL Error'#13#10'SQL error code = ';
IB_STATEMENT = #13#10'STATEMENT:';
var
APos: integer;
begin
APos:=Pos(IBERR_PREFIX, S);
if APos > 0 then
result:=Trim(Copy(S, APos+Length(IBERR_PREFIX)+1, Length(S)))
else
result:=S;
APos:=Pos(IB_DYN_SQL_ERR, result);
if APos > 0 then begin
delete(result, APos, Length(IB_DYN_SQL_ERR));
APos:=Pos(#13#10, result);
if APos > 0 then
delete(result, 1, APos+1);
end;
APos:=Pos(IB_STATEMENT, result);
if APos > 0 then
Delete(Result, APos, Length(result)-APos+1);
result:=trim(result);
end;
--
Regards,
Bj�rge S�ther
bjorge@haha_itte.no
"Svein Erling Tysvaer" <svein.erling.tysvaer@...> skrev i
melding news:5.1.0.14.0.20030307113227.02b6b8d0@[158.36.132.22]...
> Bj=F8rge,how=
> haven't you bought the Getting Started Guide? At $29.50 it teaches you
> =20sample
> to do exactly this - both as a standalone control and within a grid.
>
> Set
>
> At 02:24 07.03.2003 +0100, you wrote:
> >An example: I tried to make TIB_LookupCombo work, and I studied the
> >app for an hour or so trying to locate the difference between my code and___________________________________________________________________________
> >the sample app's. finally I had tried so many different combinations of
> >property settings, I still wasn't 100% sure I knew what actually made it
> >work.
>
>
>
>
> IB Objects - direct, complete, custom connectivity to Firebird orInterBase
> without the need for BDE, ODBC or any other layer.___________________________________________________________________________
>
> http://www.ibobjects.com - your IBO community resource for Tech Infopapers=
> ,=
> keyword-searchable FAQ, community code contributions and more !
> =20http://docs.yahoo.com/info/terms/=20
>
> Your use of Yahoo! Groups is subject to
>
>
>