[ic] page generation for the admin area orders

Peter peter at pajamian.dhs.org
Tue Nov 1 23:25:30 EST 2005

On 11/01/2005 06:53 PM, James P. Kinney III wrote:
>>On 11/01/2005 05:14 PM, James P. Kinney III wrote:
>>>table transactions: set_slice error as called by Vend::Data: DBD::Pg::st
>>>execute failed: ERROR: invalid input syntax for type timestamp: "" 
> I looked at the transactions.txt file and the update_date had only the
> YYYYMMDD portion.  The Postgresql docs indicate that is a valid format
> for the date function.
It is, however, according to your error message it is explicitly trying 
to write an empty string ("") to a field of type timestamp.

> But there was no time portion. So I added one to
> make the format follow the postgresql docs (the same one you used, but
> minus the .mmmmmmm)
The .mmmmmm is optional, I include it for completeness and to count the 
number of chars needed in the field for a varchar type (in case postgres 
tries to write that number of chars to the field).

> and it barfed on restarting with the same error (I
> forced a reload of the transactions.txt file. There were only 4 entries
> as this is still a test setup). Of course it goes away when I modify the
> dbconf settings to use varchar(23) instead of timestamp.
I'm guessing that update_date is a field you've added.  There is a 
reason that IC uses varchar to store dates in the demo catalogs (I've 
learned this the hard way).  What happens is that IC will truncate an 
overlength field to the number of chars that postgres tells it should be 
in that field.  This is to avoid having postgres barf from an overlength 
field.  I think it gets confused by the timestamp type and thinks that 
it is supposed to have a length of 0.  Here's one workaround:

Look for a line like this in the .pgsql file for the table you're having 
problems on and comment it out with a hash (#) at the beginning:
Database  userdb  LENGTH_EXCEPTION_DEFAULT  truncate_log

Then IC will no longer try to truncate overlength fields.  Bear in mind 
that if you have a different field in the table of type varchar and IC 
then trys to write too much data to it postgres will barf and you'll get 
another error by doing this.

> Hmm. This is data that was written by IC and it is invalid. 
IC really just ends up writing what you tell it to in the end.


More information about the interchange-users mailing list