----- Original Message -----
From: <firebird-support@yahoogroups.com>
To: <firebird-support@yahoogroups.com>
Sent: Thursday, November 20, 2003 10:27 PM
Subject: [firebird-support] Digest Number 1881


>
> To unsubscribe from this group, send an email to:
> firebird-support-unsubscribe@yahoogroups.com
>
>
> ------------------------------------------------------------------------
>
> There are 3 messages in this issue.
>
> Topics in this digest:
>
> 1. Re: Change column type NULL to NOT NULL
> From: "Alexander V.Nevsky" <ded@...>
> 2. Re: Re: Change column type NULL to NOT NULL
> From: Daniel Rail <daniel@...>
> 3. Re: Locking mechanisms
> From: Ann Harrison <aharrison@...>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 1
> Date: Thu, 20 Nov 2003 17:44:09 -0000
> From: "Alexander V.Nevsky" <ded@...>
> Subject: Re: Change column type NULL to NOT NULL
>
> --- In firebird-support@yahoogroups.com, "skotaylor" <scott@d...>
> wrote:
> > I'm having an SQL <alt_col_clause> crisis. Trying to follow the
> > SQLRef for ALTER TABLE and can't seem to quite get the right syntax.
> > I want to convert a NULL field to be NOT NULL.
>
> This opertion can't be made using ALTER TABLE. Why - I don't know.
> Popular interactive tools allow this making updates of system tables.
> I'm sure about IBExpert, seems IBWorkBench allow this too. Beware - if
> columns really conatins nulls, gbk of this database will be
> unrestorable after this, perhaps this is the reason why such alter is
> not performed by standard DDL statement. So at least
>
> update table set column=something where column is null
>
> is necessary. Usually more sophisticated algorithm is needed because
> if you want this then it usually mean column should contain
> substantial data not predicted in previous design.
>
> Best regards,
> Alexander.
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 2
> Date: Thu, 20 Nov 2003 14:11:01 -0400
> From: Daniel Rail <daniel@...>
> Subject: Re: Re: Change column type NULL to NOT NULL
>
> Hi,
>
> At November 20, 2003, 13:44, Alexander V.Nevsky wrote:
>
> > wrote:
> >> I'm having an SQL <alt_col_clause> crisis. Trying to follow the
> >> SQLRef for ALTER TABLE and can't seem to quite get the right syntax.
> >> I want to convert a NULL field to be NOT NULL.
>
> > This opertion can't be made using ALTER TABLE. Why - I don't know.
> > Popular interactive tools allow this making updates of system tables.
> > I'm sure about IBExpert, seems IBWorkBench allow this too. Beware - if
> > columns really conatins nulls, gbk of this database will be
> > unrestorable after this, perhaps this is the reason why such alter is
> > not performed by standard DDL statement.
>
> Maybe what is required in the engine, before changing a field from
> NULL to NOT NULL, is a simple check on all the values of that field to
> make sure that no values are NULL. And, if all the values are NOT
> NULL, then add the NOT NULL constraint, otherwise return an error
> message indicating that it cannot be performed because at least on
> value is NULL. I know, this can be an expensive task, if there are a
> lot of rows in the table. It could be added as a feature request in
> the tracker.
>
> --
> Best regards,
> Daniel Rail
> Senior System Engineer
> ACCRA Group Inc. (www.accra.ca)
> ACCRA Med Software Inc. (www.filopto.com)
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 3
> Date: Thu, 20 Nov 2003 14:47:04 -0500
> From: Ann Harrison <aharrison@...>
> Subject: Re: Locking mechanisms
>
> At November 20, 2003, 10:07, Sandy wrote:
>
> >>To put it another way, transaction A starts editing a record. While this
is
> >>going on, transaction B opens the same record and makes a change, and
> >>commits. Later on, transaction A finally commits, overwriting the work
of
> >>transaction B.
> >>
> >>I am accustomed to solving this sort of problems with locks, but from
what
> >>I've read, Firebird doesn't support much in the way of locking. Does
anyone
> >>know the solution to this of problem?
> >>
> Daniel Rail wrote:
>
> > Firebird 1.5 has introduced locking capability. You can read about it
> > in the release notes for FB 1.5. You can get the release notes here:
> > http://www.ibphoenix.com/downloads/Firebird_v15.106_ReleaseNotes.pdf
>
> Which transaction do you want to fail? From your example, I'd guess that
you'd rather have B succeed and A fail, which is not what will happen with
locking. If that _is_ what you want, use the repeatable read transaction
mode. If you want A to succeed and B to fail, use record locking.
>
> Regards,
>
> Ann
>
>
>
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>