Thread: ODBC CREATE TABLE failures

ODBC CREATE TABLE failures

From
"Michael J. Sheldon"
Date:
I've just started testing postgreSQL as a backend database for an
NT-based intranet application running on Cold Fusion.

The application will automatically create the database structure if it
does not already exist, by executing a series of CREATE TABLE statements
through the ODBC driver.

However, only the first table is being created.

Each statement is in a separate request, and any one statement will
execute, but only if it is the first. Even more puzzling is the fact
that subsequent calls do not throw an error. The first error I see is
when an attempt is made to insert data into a non-existent table.

The application has tested out fine on both MS Access and MS SQL Server.

The ODBC driver version is 6.40.0002

Code follows:
(For those not familiar with Cold Fusion, the <CFQUERY> tags specify a
distinct database call. #attributes.datasource# is a variable name
containing the DSN)

<CFQUERY DATASOURCE="#attributes.datasource#">
    CREATE TABLE FMGroups
    (
    GroupID INTEGER NOT NULL,
    GroupName VARCHAR(64) NOT NULL,
    Description VARCHAR(100),
    CONSTRAINT ID_pk PRIMARY KEY (GroupID),
    CONSTRAINT check_directory UNIQUE (GroupName)
    )
</CFQUERY>
<CFQUERY DATASOURCE="#attributes.datasource#">
    CREATE TABLE FMDirectories
    (
    DirectoryID INTEGER NOT NULL,
    DirectoryName VARCHAR(64) NOT NULL,
    Description VARCHAR(100),
    ParentID INTEGER NOT NULL,
    CONSTRAINT ID_pk PRIMARY KEY (DirectoryID),
    CONSTRAINT check_directory UNIQUE (DirectoryName)
    )
</CFQUERY>
<CFQUERY DATASOURCE="#attributes.datasource#">
    CREATE TABLE FMFiles
    (
    FileID INTEGER NOT NULL,
    DirectoryID INTEGER,
    FilePath VARCHAR(255) NOT NULL,
    DisplayName VARCHAR(100) NOT NULL,
    Description VARCHAR(100),
    AddedBy VARCHAR(64) NOT NULL,
    DateModified datetime NOT NULL,
    CONSTRAINT ID_pk PRIMARY KEY (FileID),
    CONSTRAINT check_path UNIQUE (FilePath),
    CONSTRAINT check_directory FOREIGN KEY (DirectoryID) REFERENCES
FMDirectories (DirectoryID)
    )
</CFQUERY>
<CFQUERY DATASOURCE="#attributes.datasource#">
    CREATE TABLE FMPermissions
    (
    GroupID INTEGER NOT NULL,
    DirectoryID INTEGER NOT NULL,
    Permissions INTEGER NOT NULL,
    CONSTRAINT ID_pk PRIMARY KEY (GroupID, DirectoryID),
    CONSTRAINT check_group FOREIGN KEY (GroupID) REFERENCES FMGroups
(GroupID),
    CONSTRAINT check_directoryID FOREIGN KEY (DirectoryID)
REFERENCES FMDirectories (DirectoryID)
    )
</CFQUERY>
<CFQUERY DATASOURCE="#attributes.datasource#">
    CREATE TABLE FMUserGroups
    (
    USERNAME VARCHAR(64) NOT NULL,
    GroupID INTEGER NOT NULL,
    CONSTRAINT check_groupID FOREIGN KEY (GroupID) REFERENCES
FMGroups (GroupID),
    CONSTRAINT ID_pk PRIMARY KEY (USERNAME)
    )
</CFQUERY>

Michael J. Sheldon
CBR Communications
Graphic design and Internet services.
A division of Commercial Blueprint Co., Inc.
http://www.cbrcomm.com
(602)707-1545

PGP Key available on request

Re: [INTERFACES] ODBC CREATE TABLE failures

From
"Thomas G. Lockhart"
Date:
> The application will automatically create the database structure if it
> does not already exist
> However, only the first table is being created.
> Code follows:
<snip>

You can test this code by running it through psql, and it fails there
too. Each CREATE TABLE statement is trying to use the same label for the
primary key constraint, but since Postgres enforces the primary key by
generating an implicit index this fails. Try using unique names for
constraints!

If for some reason these constraint names *must* be identical, you could
consider modifying the code in the parser to generate a unique internal
name based on both the constraint name and the table name, for example.
There is already a routine there to help you do this.

Failure example follows...

                  - Tom

postgres=>         CREATE TABLE FMGroups
postgres->         (
postgres->         GroupID INTEGER NOT NULL,
postgres->         GroupName VARCHAR(64) NOT NULL,
postgres->         Description VARCHAR(100),
postgres->         CONSTRAINT ID_pk PRIMARY KEY (GroupID),
postgres->         CONSTRAINT check_directory UNIQUE (GroupName)
postgres->         );
NOTICE:  CREATE TABLE/PRIMARY KEY will create implicit index id_pk for
table fmgroups
NOTICE:  CREATE TABLE/UNIQUE will create implicit index check_directory
for table fmgroups
CREATE
postgres=>         CREATE TABLE FMDirectories
postgres->         (
postgres->         DirectoryID INTEGER NOT NULL,
postgres->         DirectoryName VARCHAR(64) NOT NULL,
postgres->         Description VARCHAR(100),
postgres->         ParentID INTEGER NOT NULL,
postgres->         CONSTRAINT ID_pk PRIMARY KEY (DirectoryID),
postgres->         CONSTRAINT check_directory UNIQUE (DirectoryName)
postgres->         );
NOTICE:  CREATE TABLE/PRIMARY KEY will create implicit index id_pk for
table fmdirectories
NOTICE:  CREATE TABLE/UNIQUE will create implicit index check_directory
for table fmdirectories
ERROR:  Cannot create index: 'id_pk' already exists

Re: [INTERFACES] ODBC CREATE TABLE failures

From
Byron Nikolaidis
Date:
Michael J. Sheldon wrote:

> I've just started testing postgreSQL as a backend database for an
> NT-based intranet application running on Cold Fusion.
>
> The application will automatically create the database structure if it
> does not already exist, by executing a series of CREATE TABLE statements
> through the ODBC driver.
>
> However, only the first table is being created.
>
> Each statement is in a separate request, and any one statement will
> execute, but only if it is the first. Even more puzzling is the fact
> that subsequent calls do not throw an error. The first error I see is
> when an attempt is made to insert data into a non-existent table.
>
> The application has tested out fine on both MS Access and MS SQL Server.
>

I would like to rule out any odbc driver problems.  Can you please send me a
copy of the "psqlodbc.log" file of the session in question?  That would be a
minimum, and if you want, you could also send an odbc trace log of the
session which, together with the other log, would give me all the
information I need.

Byron