Thread: suddenly changed behaviour

suddenly changed behaviour

From
"Coby Beck"
Date:
Hi,

Below is a snippet of code that is generated via another program:

CREATE TABLE tActuals
(
        kActual INTEGER NOT NULL DEFAULT NEXTVAL('kActual') PRIMARY KEY,
        fActualID TEXT,
        fAllocationCode TEXT,
        fWorkItemCode TEXT,
        fInvoicedAmount FLOAT,
        fDescription TEXT NOT NULL DEFAULT '<TEXTAREA rows=4 cols=50
tabindex=1 name=**FORMFIELD**></TEXTAREA>',
        pSUPPLIER INTEGER NOT NULL DEFAULT 0,
        fSupplierCode TEXT NOT NULL DEFAULT
''||dSupplierMenu('**FORMFIELD**','')||'',
        pBATCHENTRY INTEGER NOT NULL DEFAULT 0
);

I have reformatted it and snipped the bulk of fields.  The code chunks in
quotes given as default values are part of a complicated hack so that the
Zope application server will present some customized html where otherwise
there would just be a normal small textbox.  This is not my design but it
has served its purpose and I have used similar tricks all over the place in
an application I am working on.

Now for reasons unknown, Posgres will not build the data base.  I have
verified that the Create statement that fails now is identical to what was
working one hour ago.  A very simple function that merely returned a foreign
key field given the primary key was taking 60+ seconds to return on my
development version of the dB so I decided to drop the dB and build it
again.

I now get the error  "Relation "tsuppliers" does not exist" which happens
during execution of dSupplierMenu, which makes sense because tSuppliers
comes later in the file but does not make sense because there should be no
function call yet.  That should happen at run time when Zope fill in default
values.

Any one have any ideas what might be different, how I can restore it and
optionally how it might have happened?  I am using 7.2 (yes I know, but
upgrading is a bit of a difficulty at the moment)

Thanks in advance for assistance!

Coby Beck