Subject | Re: [ib-support] Re: Firebird performance |
---|---|
Author | Helen Borrie |
Post date | 2003-02-24T11:42:21Z |
At 10:03 AM 24/02/2003 +0000, you wrote:
all live in a database named isc4.gdb (for now...)
INSERT INTO USERS(
USER_NAME,
PASSWD,
FIRST_NAME,
MIDDLE_NAME,
LAST_NAME
)
VALUES(
'GWB',
'okmommy',
'George',
'Dubbya',
'Bush'
);
There's also nothing to stop SYSDBA from writing its own stored procedures
to modify USERS.
where you got the idea that it's not going to be hard work to define your
own API layer from scratch in VB. I guess you know that it's already done
for you in the ODBC drivers...?
which I mean that, whatever language you do it in, it boils down to
defining those communication structures, populating them, and providing
vehicles to receive the structures that come back.
database server. Dependence on host platform and language is not what
Firebird is about. There is no Delphi inside the Firebird server or the
client library. No interpreted code. No run-time compiling.
the API library full of hundreds of rarely-used functions, and making it do
run-time compiling of interpreted code...
heLen
>I will try FB 1.5 after these smart guys will get an final release. IWhy not do it yourself? Only SYSDBA can add users, but the server's users
>wonder if there are planned some features that are useful in MS-SQL
>Server, like all those stored procedure implmented by the system
>("sp_xxxx"). E.g., I miss the feature to add users via SQL
>(the "sp_adduser" in MS-SQL Server) -
all live in a database named isc4.gdb (for now...)
INSERT INTO USERS(
USER_NAME,
PASSWD,
FIRST_NAME,
MIDDLE_NAME,
LAST_NAME
)
VALUES(
'GWB',
'okmommy',
'George',
'Dubbya',
'Bush'
);
There's also nothing to stop SYSDBA from writing its own stored procedures
to modify USERS.
>yes, there-s an API-call to doIt's a question of defining and populating structures and I don't know
>this, but I can't get the API-calls to work by Visual Basic (that's
>the language I use), even if I'm not a newbie calling DLL's from VB.
where you got the idea that it's not going to be hard work to define your
own API layer from scratch in VB. I guess you know that it's already done
for you in the ODBC drivers...?
>I understood that it was easy to work with all API's from Delphi,It's no easier or harder with Delphi than with any other language -- by
which I mean that, whatever language you do it in, it boils down to
defining those communication structures, populating them, and providing
vehicles to receive the structures that come back.
>butMicrosoft chooses to allow (or force) you to do VB stuff inside its
>Firebird has no more to be related to Borland environments, and each
>developer should have the chance to get it's work don as easy as
>possible - that's why I'm asking for tasks done inside Firebird, like
>the one I've mentioned before.
database server. Dependence on host platform and language is not what
Firebird is about. There is no Delphi inside the Firebird server or the
client library. No interpreted code. No run-time compiling.
> > use, but also periodically updating 100.000 records or more, orexporting a
> > million records with hardly perceptible impact for other users.Stop to ponder what the impact would be of stuffing the server engine and
>Wow, that sounds good! ;)
the API library full of hundreds of rarely-used functions, and making it do
run-time compiling of interpreted code...
heLen