Loading ...
Sorry, an error occurred while loading the content.
 

Re: [firebird-support] Re: Cannot create tables in new FB 2.5 DB, fails with error 335544351 on commit

Expand Messages
  • Lester Caine
    ... I d extend that by saying that I USUALLY see this error when I ve left out names for indexes and it s trying to create a second RDB$PRIMARY11 for some
    Message 1 of 14 , Jan 1, 2011
      Paul Vinkenoog wrote:
      > Peter: there's something very weird going on in your database. FWIW, I also ran your DDL (on 2.5) and it worked flawlessly.
      >
      > The message "cannot create index RDB$PRIMARY11" suggests there may be something wrong with your system tables.

      I'd extend that by saying that I USUALLY see this error when I've left out names
      for indexes and it's trying to create a second 'RDB$PRIMARY11' for some reason.
      I usually know straight away where I've cocked up, but when one is up in the
      600's, a quick check on the system tables for the index often clears up the problem.

      --
      Lester Caine - G8HFL
      -----------------------------
      Contact - http://lsces.co.uk/wiki/?page=contact
      L.S.Caine Electronic Services - http://lsces.co.uk
      EnquirySolve - http://enquirysolve.com/
      Model Engineers Digital Workshop - http://medw.co.uk//
      Firebird - http://www.firebirdsql.org/index.php
    • peterbelow@ymail.com
      ... No, there is no autocommit, if I leave out the commit, close FlameRobin and restart it the table is not there. Also keep in mind that this also fails in
      Message 2 of 14 , Jan 1, 2011
        --- In firebird-support@yahoogroups.com, "Woody" <woody-tmw@...> wrote:
        > Are you sure the DDL isn't already autocommitted inside of FlameRobin? I've
        > never used it so I'm not sure how it works. Maybe someone else can jump in
        > here with other ideas.
        >

        No, there is no autocommit, if I leave out the commit, close FlameRobin and restart it the table is not there. Also keep in mind that this also fails in ISQL, and that *does* autocommit for DDL by default.

        --
        Peter
      • peterbelow@ymail.com
        ... Thanks for the hint, Lester. I could not find any indices with names like the above, but there definitely was something corrupted in my database, probably
        Message 3 of 14 , Jan 1, 2011
          --- In firebird-support@yahoogroups.com, Lester Caine <lester@...> wrote:
          >
          > Paul Vinkenoog wrote:
          > > Peter: there's something very weird going on in your database. FWIW, I also ran your DDL (on 2.5) and it worked flawlessly.
          > >
          > > The message "cannot create index RDB$PRIMARY11" suggests there may be something wrong with your system tables.
          >
          > I'd extend that by saying that I USUALLY see this error when I've left out names
          > for indexes and it's trying to create a second 'RDB$PRIMARY11' for some reason.
          > I usually know straight away where I've cocked up, but when one is up in the
          > 600's, a quick check on the system tables for the index often clears up the problem.
          >

          Thanks for the hint, Lester. I could not find any indices with names like the above, but there definitely was something corrupted in my database, probably due to my first bungled attempts to create this table. I followed Paul's advice to start with a new database, and this now seems to work:

          ISQL Version: WI-V2.5.0.26074 Firebird 2.5
          Use CONNECT or CREATE DATABASE to specify a database
          SQL> CREATE DATABASE 'c:\daten\datenbanken\sf\test.fdb'
          CON> user 'peter'
          CON> password 'perry';
          Server version:
          WI-V2.5.0.26074 Firebird 2.5
          WI-V2.5.0.26074 Firebird 2.5/XNet (PBDELL)/P12
          WI-V2.5.0.26074 Firebird 2.5/XNet (PBDELL)/P12
          SQL> CREATE DOMAIN OidKey AS CHAR(22);
          SQL> commit;
          SQL> CREATE TABLE HL_Oids (
          CON> OID OidKey NOT NULL CONSTRAINT PK_OIDs PRIMARY KEY
          CON> );
          SQL> commit;
          SQL> show table HL_Oids;
          OID (OIDKEY) CHAR(22) Not Null
          CONSTRAINT PK_OIDS:
          Primary key (OID)
          SQL>

          So I'm now hopefully able to proceed with this project.

          Thanks to all who participated in this thread, and a happy and successful 2011!

          --
          Peter
        • Ann W. Harrison
          ... If you still have the broken database, I d be mildly interested in seeing what happened, assuming that it compresses to a size you can email. Thanks, Ann
          Message 4 of 14 , Jan 2, 2011
            On 1/1/2011 8:00 AM, peterbelow@... wrote:
            >
            >
            > Thanks for the hint, Lester. I could not find any indices with names like the above, but there definitely was something corrupted in my database, probably due to my first bungled attempts to create this table. I followed Paul's advice to start with a new database, and this now seems to work:
            >

            If you still have the broken database, I'd be mildly interested in
            seeing what happened, assuming that it compresses to a size you can
            email.


            Thanks,

            Ann
          • Michael Ludwig
            ... And I used to think I know messiness when I see some. If you don t mind my asking, what exactly is *messy* about the above DDL snipped? The constraint name
            Message 5 of 14 , Jan 2, 2011
              Helen Borrie schrieb am 01.01.2011 um 08:09 (+1300):
              > >
              > >CREATE TABLE HL_Oids (
              > > OID OidKey NOT NULL CONSTRAINT PK_OIDs PRIMARY KEY
              > >);

              > Nevertheless, I don't consider this a tidy way to do table DDL.
              > You save a couple of keystrokes and have a messy DDL script.

              And I used to think I know messiness when I see some. If you don't
              mind my asking, what exactly is *messy* about the above DDL snipped?
              The constraint name is included, so it looks orderly to me.

              > I prefer:
              >
              > create table HL_Oids (
              > OID OidKey NOT NULL,
              > <other columns>,
              > constraint PK_OIDS PRIMARY KEY(OID)
              > );
              > commit;
              >
              > Some people prefer:
              > create table HL_Oids (
              > OID OidKey NOT NULL,
              > <other columns>);
              > commit;
              > alter table HL_Oids
              > add constraint PK_OIDS PRIMARY KEY(OID);
              > commit;

              How and why are these forms less messy?

              I'm seeing all of these forms in the wild and now I'm suspecting
              to be unaware of some possibly subtle but important difference.

              Happy New Year to all!
              --
              Michael Ludwig
            • Helen Borrie
              ... However, most DDL scripts have many table definitions and many tables have multiple constraints. If you have only ginger and marjoram in your spice
              Message 6 of 14 , Jan 2, 2011
                At 01:39 PM 3/01/2011, Michael Ludwig wrote:
                >Helen Borrie schrieb am 01.01.2011 um 08:09 (+1300):
                >> >
                >> >CREATE TABLE HL_Oids (
                >> > OID OidKey NOT NULL CONSTRAINT PK_OIDs PRIMARY KEY
                >> >);
                >
                >> Nevertheless, I don't consider this a tidy way to do table DDL.
                >> You save a couple of keystrokes and have a messy DDL script.
                >
                >And I used to think I know messiness when I see some. If you don't
                >mind my asking, what exactly is *messy* about the above DDL snipped?
                >The constraint name is included, so it looks orderly to me.

                However, most DDL scripts have many table definitions and many tables have multiple constraints.

                If you have only ginger and marjoram in your spice cupboard, you can quickly find either. If you have 50 spices and 50 herbs, it is tidier and a lot easier to find a spice and a herb if the spices are on one shelf and the herbs on another. For me, tidy DDL scripts use shelves. ;-)

                ./hb
              • Michael Ludwig
                ... Thanks. That makes sense. Off to buy some shelves now. -- Michael Ludwig
                Message 7 of 14 , Jan 3, 2011
                  Helen Borrie schrieb am 03.01.2011 um 14:19 (+1300):
                  > At 01:39 PM 3/01/2011, Michael Ludwig wrote:
                  >
                  > If you have only ginger and marjoram in your spice cupboard, you can
                  > quickly find either. If you have 50 spices and 50 herbs, it is tidier
                  > and a lot easier to find a spice and a herb if the spices are on one
                  > shelf and the herbs on another. For me, tidy DDL scripts use shelves.
                  > ;-)

                  Thanks. That makes sense. Off to buy some shelves now.

                  --
                  Michael Ludwig
                Your message has been successfully submitted and would be delivered to recipients shortly.