simply delete then insert commands
-host=192.168.0.82 -user=dev2admin -pw=Welcome!17 -db=owen_test
delete from w2emails where account_number = "123456789"
2
insert into w2emails (customer_code, account_number, email_address, confirmed, a
ctive, text, phone_number, user_name, user_password)
values ('XXXXXX',"123456789",'oedwards@valli.com','','','','','oedwards','valli'
)
0
delete does not work, add does using below to launch

/eis/vm/miame/bin/ashell -n -q -i /eis/vm/miame/miame.ini

-host=192.168.0.82 -user=dev2admin -pw=Welcome!17 -db=owen_test
delete from w2emails where account_number = "123456789"
0
insert into w2emails (customer_code, account_number, email_address, confirmed, a
ctive, text, phone_number, user_name, user_password)
values ('XXXXXX',"123456789",'oedwards@valli.com','','','','','oedwards','valli'
)
0
works using below to launch ashell
/eis/vm/miame/bin/ashell -d -i /eis/vm/miame/miame.ini

i use the prior to launch background jobs, later normal jobs.

i cannot get my background jobs to function correctly my ashsql.

what am i missing here?

should have added the output from the error

cmdhdr.lastop = 9
cmdhdr.handle = 1
cmdhdr.rc = 2 [DBMS error - see cmdhdr.rcext]
cmdhdr.rcext = 1
cmdhdr.sqlstate = HY000 (General Error)
<-----
Retrieving DBMS error message for # 1
DMBS error msg:
---->
cmdhdr.info1: 0 (n/a)
info2: 0 (n/a)

Ah, you answered my first question before I posted it. I wasn't sure whether the single digit codes were the returned rc values and was going to suggest you use SQLOP_GET_ERRMSG to get more info. But apparently that wasn't very helpful, and neither is the HY000 "general error".

Also, the listing doesn't show the results of a query on the items to be deleted, so it isn't clear that they actually exist prior the start of the test.

But assuming the items did exist and that the delete is failing for some mysterious reason purely related either to launching with the quiet switch (-q), or to running in background, then I'll need to try to set up a test here to duplicate it. Offhand I can't see any obvious reason why either of those factors should have any bearing on the SQL operations.

I got diverted off onto several tangents in the course of investigating this, but in the end, I can't seem to reproduce it.

Perhaps you can create a slightly more complete test case, consisting of dropping the table, creating it, adding a few records, then deleting some of them, then doing a select * to output the number remaining. Then maybe we can run it in multiple environments and compare the results.

Another tip would be to use .SETENV ASQLTRACE=1 before running your test which will produce a very detailed trace in ashlog.log. Maybe in that it will be easier to see exactly what is different.

whoops. i forgot to set the connectionstring before i started the process, all works as promised now, sorry about that

Well I guess the wild goose chase wasn't all for naught, as it did lead me to an obscure bug related to use of F,4 fields in a FETCH_ROW operation. That's fixed in 6.4.1556.0, soon to be posted, but apparently that variable type is not very popular, so there's probably no particular need to update on account of it. (Of all places, it is used in the SQLTEST4 sample program, which is what I was using to try to reproduce the problem.)