firebird-docs

[Firebird-docs] Help

[<jro...@ya...>]

I need one comparison between Firebird vs. Postgres in spanish or
english.  Thank you

=====
Jose S. Romero
Advanced Systems - Soluciones Informáticas
Paraná - Entre Ríos - Argentina

Ahora podés usar Yahoo! Messenger desde tu celular. Aprendé cómo hacerlo en Yahoo! Móvil: http://ar.mobile.yahoo.com/sms.html

Re: [Firebird-docs] Help

[Bojidar A. <boj...@ya...>]

IMHO There are no good ones.

Post in groups.yahoo.com - ib-support  It is official supporting newsgroup.
if you don't get answer here.


--
Bojidar Alexanrov
Kodar Ltd.
http://www.Kodar.net
Jose Romero wrote:
> I need one comparison between Firebird vs. Postgres in spanish or
> english.  Thank you
>
> =====
> Jose S. Romero
> Advanced Systems - Soluciones Informáticas
> Paraná - Entre Ríos - Argentina
>
> Ahora podés usar Yahoo! Messenger desde tu celular. Aprendé cómo
> hacerlo en Yahoo! Móvil: http://ar.mobile.yahoo.com/sms.html
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com
> Understand how to protect your customers personal information by
> implementing SSL on your Apache Web Server. Click here to get our
> FREE Thawte Apache Guide:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
> _______________________________________________ Firebird-docs mailing
> list Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-docs

Re: [Firebird-docs] Help

[Thad H. <th...@mi...>]

The most significant difference I've found is transaction control where
Firebird wins hands down!  For example, Postgres does not support nested
transactions.  Firebird does--you just have to name them.

Postgres does have a wealth of functions but I think Firebird UDFs will
soon catch up here.  Already 1.0.2 supports NULLIF() and NVL().

On Thu, 16 Jan 2003 16:46:48 -0500, Jose Romero wrote:

> I need one comparison between Firebird vs. Postgres in spanish or
> english.  Thank you

-- 
------------------------------------------------------------------------
Thad Humphries              "...no religious test shall ever be required
Web Development Manager      as a qualification to any office or public
Phone: 540/675-3015, x225    trust under the United States." -Article VI

Re: [Firebird-docs] Help

[Helen B. <he...@tp...>]

At 05:02 PM 30/01/2003 -0500, you wrote:
>The most significant difference I've found is transaction control where
>Firebird wins hands down!  For example, Postgres does not support nested
>transactions.  Firebird does--you just have to name them.

No, Firebird doesn't support nested transactions.   It does supported 
nested stored procedures.  Firebird 2 will have named savepoints.


>Postgres does have a wealth of functions but I think Firebird UDFs will
>soon catch up here.

Firebird isn't likely to aim to "catch up" with the bloatedness of PG and 
others.  Some functions considered essential are being added to the 
language but FB isn't likely to change its stance radically and overload 
the engine with rarely-used functions.  Firebird's small footprint is one 
of its big assets.  UDFs can be added at any time and we'll see "the best" 
of new UDFs being made available in more new UDF libraries.  There are 
already a lot available...the community needs to do a better job at 
publicising where to get them.

>Already 1.0.2 supports NULLIF() and NVL().

It does;  but the need for those UDFs has gone in Firebird 1.5, which 
supports COALESCE.  I think CASE is there too, or in the process of being 
implemented.

regards,
Helen

Re: [Firebird-docs] Help

[Thad H. <th...@mi...>]

On Thu, 30 Jan 2003 14:09:19 -0500, Helen Borrie wrote:

> At 05:02 PM 30/01/2003 -0500, you wrote:
>>The most significant difference I've found is transaction control where
>>Firebird wins hands down!  For example, Postgres does not support nested
>>transactions.  Firebird does--you just have to name them.
> 
> No, Firebird doesn't support nested transactions.   It does supported
> nested stored procedures.  Firebird 2 will have named savepoints.

Maybe I didn't choose my words correctly.  PostgreSQL docs seems to call
it nested when you start another transaction before committing or rolling
back the current transactions. (I believe the book where it said
'PostgreSQL does not handle embedded transactions' was "Postgresql:
Developer's Handbook" by Geschwinde, Schoenig, and Schonig.)  Maybe I
should say "simultaneous"?  If I've used the term incorrectly, sorry.
Please let me know what I should call it.

Whatever it's called (and please correct me), it was the brick wall I hit
when I first tried porting from Oracle to PostgreSQL.  In PostgreSQL,
committing any transaction closes all transactions.  In the embedded SQL I
just I just ported, there are many instances where I run one or more named
transactions inside another--or, at least, while another one is executing.

For example, in the .e file that accesses the database, I have two
functions.  The first opens a cursor into a table and fetches record. The
second closes it.  (Since we use other databases, I also have Oracle *.pc,
Sybase *.cp, and Informix *.ep version of this, each tailored to their own
peculiar embedded SQL implementation.)

----------------- .e file ----------------------

static XSQLDA   *out_sqlda;		/* XSQLDA struct for all output params	*/
static isc_tr_handle    ent_trans;  /*  transaction for get_dbrec_ent() */
int entflag = FALSE;
...

int get_dbrec_ent( dbrec r )
{
  EXEC SQL BEGIN DECLARE SECTION;
  char		thesql[1024];
  EXEC SQL END DECLARE SECTION;
  EXEC SQL WHENEVER SQLERROR GO TO e_error; 
  EXEC SQL WHENEVER NOT FOUND GO TO e_notfound;

  if ( entflag == FALSE ) {
    memset( thesql, 0, sizeof thesql );
    strcpy( thesql, "SELECT " );
    ...
    /* allocate XSQLDA */

    ent_trans = (isc_tr_handle) NULL;
    EXEC SQL SET TRANSACTION NAME ent_trans READ ONLY; 
    EXEC SQL PREPARE TRANSACTION ent_trans statement FROM :thesql; 
    EXEC SQL DESCRIBE OUTPUT statement INTO SQL DESCRIPTOR out_sqlda; 
    ...
    /* allocate XSQVARS */

    EXEC SQL DECLARE scrnc CURSOR FOR statement; 
    EXEC SQL OPEN TRANSACTION ent_trans cursor;

    entflag = TRUE;
  }
  
  EXEC SQL FETCH cursor USING SQL DESCRIPTOR out_sqlda; 
  ...
  /* convert to  my dbrec structure */

  return 0;

  e_notfound:
  EXEC SQL WHENEVER NOT FOUND CONTINUE; 
  return E_NOREC;

  e_error:
  EXEC SQL WHENEVER SQLERROR CONTINUE;
  return DB_ERROR;
}

void end_o_dbrec_ent()
{
  entflag	= FALSE;
  EXEC SQL CLOSE cursor;
  ...
  /* free XSQLVARS and XSQLDA */
  /* commit ent_trans transaction */
}

----------------- .e file ----------------------

Now in my *.c file, I access get_dbrec_ent() in a loop.  This loop may
well call funtions in other *.e files, functions which create, execute,
and commit/rollbacktheir own transactions.

while( get_dbrec_ent( &mydbrec ) == 0 ) {
  ...
}
end_o_dbrec_ent();

I have tested cases of five and more transactions running at the same
time with Firebird.  This was not possible with PostgreSQL because the
first commit/rollback closed down everything.
-- 
------------------------------------------------------------------------
Thad Humphries              "...no religious test shall ever be required
Web Development Manager      as a qualification to any office or public
Phone: 540/675-3015, x225    trust under the United States." -Article VI

Re: [Firebird-docs] Help

[Helen B. <he...@tp...>]

At 11:17 AM 31/01/2003 -0500, you wrote:
>On Thu, 30 Jan 2003 14:09:19 -0500, Helen Borrie wrote:
>
> > At 05:02 PM 30/01/2003 -0500, you wrote:
> >>The most significant difference I've found is transaction control where
> >>Firebird wins hands down!  For example, Postgres does not support nested
> >>transactions.  Firebird does--you just have to name them.
> >
> > No, Firebird doesn't support nested transactions.   It does supported
> > nested stored procedures.  Firebird 2 will have named savepoints.
>
>Maybe I didn't choose my words correctly.  PostgreSQL docs seems to call
>it nested when you start another transaction before committing or rolling
>back the current transactions.

Nested transactions is where a new transaction can be started from within 
another transaction, i.e. start a transaction from within a stored 
procedure (which is, itself inside a transaction, of course).

>(I believe the book where it said
>'PostgreSQL does not handle embedded transactions' was "Postgresql:
>Developer's Handbook" by Geschwinde, Schoenig, and Schonig.)  Maybe I
>should say "simultaneous"?  If I've used the term incorrectly, sorry.
>Please let me know what I should call it.

If PGSQL won't let you start another transaction before committing or 
rolling back the current transactions, then it doesn't support multiple 
concurrent transactions.  I don't think this is quite right, either.  Could 
it be that this restriction applies where the transactions in question have 
their isolation level attribute set to one which makes them 
serialized?  (Comparable to Fb's Consistency isolation...)


>Whatever it's called (and please correct me), it was the brick wall I hit
>when I first tried porting from Oracle to PostgreSQL.  In PostgreSQL,
>committing any transaction closes all transactions.

Odd.

>In the embedded SQL I
>just I just ported, there are many instances where I run one or more named
>transactions inside another--or, at least, while another one is executing.

Transactions (in both Fb and Oracle) run in isolation from one 
another.  The isolation level determines how isolated one transaction will 
be from any others.  Transaction isolation is the mechanism by which 
concurrent transactions can run each inside its own view of the database 
state, without compromising or being compromised by the effects of other 
transactions that started before it or that start after it.

Oracle has some kind of priority system for "who wins" when multiple 
transactions commit work on rows that other transactions are still working 
on.  If  I recall correctly, this depends on the style of lock granted to 
the transaction.

With Fb, the first to commit wins, as long as the current state of the row 
bookkeeping indicates it can.  (This needs a lot more explanation to 
understand:  it's pretty lengthy and OT for here.  You can pick up docs on 
the IBPhoenix and IBObjects sites that explain the multi-generational 
bookkeeping).


>I have tested cases of five and more transactions running at the same
>time with Firebird.  This was not possible with PostgreSQL because the
>first commit/rollback closed down everything.

Mmm, if you're going back there, it would be worthwhile finding out whether 
PG transactions are serialized by default, for some reason...

Helen