[ic] page generation for the admin area orders
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