Hi Hari.

I attemped your trigger on 9.30.UC3 and 9.40.UC2 on Linux.
Both products outputs -201.

create trigger "auth".trg_altask_del delete on "auth".aualtask
referencing old as old
for each row
(
execute procedure "auth".sp_stop_clock('D' , , ,old.doc_typ
# ^
# 201: A syntax error has occurred.
#

But If 'D' ,'' ,'' ,old.doc_typ... intead of 'D' , , ,old.doc_typ, probably
it works.

You may call IBM Informix response center to open the case.

Regards.
--
Tsutomu Ogiwara from Tokyo Japan.
ICQ#:168106592





>From: hariog@yahoo.com (Hari Gupta)
>Reply-To: hariog@yahoo.com (Hari Gupta)
>To: informix-list@iiug.org
>Subject: dbimport failed - IDS 9.30 UC3
>Date: 6 Oct 2003 00:39:12 -0700
>
>Hi,
>
>I have recently installed IDS 9.30 UC3 on Linux 7.3. Done a dbexport
>with -ss and started dbimport with -d <dbspace-name>. After about 5
>hrs, dbimport failed with following error:
>
>------------------------------------
>*** prepare sqlobj
>201 - A syntax error has occurred.
>------------------------------------
>
>The statement just above where dbimport failed was a "create trigger"
>as below:
>
>-------------------------------------------------------------------
>create trigger "auth".trg_altask_del delete on "auth".aualtask
> referencing old as old
> for each row
> (
> execute procedure "auth".sp_stop_clock('D' , , ,old.doc_typ
> ,old.doc_yer ,old.doc_num ,old.doc_prt ,old.wrk_typ ,old.seq_num
> , , , ,old.mdu_ref ));
>
>*** prepare sqlobj
>201 - A syntax error has occurred.
>-------------------------------------------------------------------
>
>Pl. note that after this create statement, all statement were update
>stats.
>So what I did, created trigger seperately and ran update stats based
>upon dbexport SQL file using dbaccess.
>
>I did read few archives about this error but none of them reported
>above error followed by 201 error.
>
>There was an issues similar to this with dbimport in earlier verson of
>IDS but I don't think it will be still an known bug with IDS 9.30 UC3.
>
>Can some guru help me about this please ?
>
>Pl. let me know if onconfig or some other info. is needed.
>
>TIA
>
>Hari

__________________________________________________ _______________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
http://join.msn.com/?page=features/virus

sending to informix-list

Thanks to David, Neil and special thanks to Tsutomu (for testing
trigger with 9.30 & 9.40) who have given me the right direction. I was
a bit concern till y'day when I did not see any reply to my post.
I was feeling orphan for a while without our newsgroup community
reply. Anyway.

I totally agree with David and his experience with Tech Support from
IBM. Sorry to say that I am also having almost simlilar experience
with IBM support through one of our application software vendor. Just
to mention an example - I have been using ER between IDS 9.21 UC3 and
IDS 9.21 TC3 for about 2 years without any major issue. Recently, we
have installed a new server and installed IDS 9.30 UC3 on primary
server. We asked especifically from IBM informix (probably IBM
Australia) if there is any known issue with ER between IDS 9.30 UC3
and IDS 9.21 TC3 and guess what ????? We were told to go ahead with
ER.Very next day the target server (which is also a production server)
crashed with an assert failure. We logged the call again with IBM and
this time they said we might need to upgrade tartget to IDS 9.30 TC6.
Is this a JOKE or CRAP ???? Anyway.

Sorry, forget to mention that I got a very good advise from Madison
Pruet thru newsgroup to use CDRSITES environment variables if we need
to use ER between two different IDS versons. That make sense.

I will contact IBM Tech support to see what they say this time.

Thanks again.

Hari

We have run into similar problems, and not just with this release. In
our case we had Stored Procedures that would not export our and import
back in due to special characters.

We learned a trick that can save you hours of watching a dbimport work
only to see it fail like you did.

We run a 'test fire'. Before you do the real import you do a simple
create database (in the dbspace you planned on putting it) and then
run the .SQL file as a script through dbaccess. This process takes
seconds or a few minutes and will check everything for syntax.

Sound an excellent trick. I will certainly try this.

Hari
"Fred Prose" <fprose@hotmail.com> wrote in message
news:195a4770.0310081229.153fe1e8@posting.google.c om...
> We have run into similar problems, and not just with this release. In
> our case we had Stored Procedures that would not export our and import
> back in due to special characters.
>
> We learned a trick that can save you hours of watching a dbimport work
> only to see it fail like you did.
>
> We run a 'test fire'. Before you do the real import you do a simple
> create database (in the dbspace you planned on putting it) and then
> run the .SQL file as a script through dbaccess. This process takes
> seconds or a few minutes and will check everything for syntax.