Data source does not support transactions.

bjkilleen · Post by **bjkilleen** » Tue Oct 28, 2003 2:28 pm

Using the InfmxCLI stage as input into a transformation stage of a server job throws the warning "This data source does not support transactions." The job completes but the warning exists.

Any assistance is appreciated.

Brad

kcbland · Post by **kcbland** » Tue Oct 28, 2003 2:40 pm

If you do a search of this forum, you see that there's an excellent discussion of your exact message in the Oliver mailing list archives.

Basically, your problem deals will the transaction log on the source table.

ray.wurlod · Post by **ray.wurlod** » Tue Oct 28, 2003 4:21 pm

You have created an Informix database without logging. Therefore, this database cannot support transactions. If you want to support transactions in an Informix database, you must create the database WITH logging.

roy · Post by **roy** » Thu Oct 30, 2003 5:33 am

Hi,
as far as I remember this is a bug (can't remember exactly where)
and no fixes will be made (as of the case we opend with ascential)

you have to accept this behaviour and move on.
the only thing that made that customer accept this was the simple fact that we were migrating the DB from informix to something else.

maybe you can flex a muscle or 2 and they'll do something about it.

Good Luck

bjkilleen · Post by **bjkilleen** » Thu Oct 30, 2003 9:57 am

Thank you all for the answers.

Brad

roy wrote:Hi,
as far as I remember this is a bug (can't remember exactly where)
and no fixes will be made (as of the case we opend with ascential)
you have to accept this behaviour and move on.
the only thing that made that customer accept this was the simple fact that we were migrating the DB from informix to something else.

maybe you can flex a muscle or 2 and they'll do something about it.

Good Luck

Amos.Rosmarin · Post by **Amos.Rosmarin** » Thu Oct 30, 2003 10:41 am

I'm with Roy ......

I first show this msg in DS5 and now it's 7 so it's about time that it will be fixed ... working without transactions it absolutely legal in Informix and should not raise a warnning message.

Hurry up before Informix disappears

) (just kidding... )

Amos

ray.wurlod · Post by **ray.wurlod** » Thu Oct 30, 2003 2:59 pm

DataStage reports all messages generated by database servers.

DataStage is not geared to work to non-transactional databases (except UniVerse and UniData), so it sends a COMMIT. Or more than one.

IDS responds to COMMIT on a non-logging database with the indicated message.

Can you suggest a generic strategy for DataStage engineers about which messages not to report? (Your answer must cover all possible stage types, including the ones not written yet.)

You can, if you hate this message so much, create a custom passive stage that emulates the functionality of the Informix stage, but which explicitly does not log this message - or, better, does not send COMMIT if connected to a non-logging database.

ariear · Post by **ariear** » Thu Oct 30, 2003 3:58 pm

Ray,
What about adding a new isolation level for instance ? I encountered a case with an ODBC stage (SELECT Only) using a gateway product connecting ADABAS. That ADABAS was read-only - whichever isolation level I tried the ODBC stage sent a COMMIT before closing the connection (And got a warning of course which messed up my SEQUENCERS !!!)

ray.wurlod · Post by **ray.wurlod** » Thu Oct 30, 2003 6:15 pm

This won't help. DataStage sends a COMMIT. There is no transaction isolation level that bypasses this. Therefore an Informix database created without logging will still generate the error message when it receives the COMMIT.

Teej · Post by **Teej** » Fri Oct 31, 2003 12:08 pm

ariear wrote:Ray,
(And got a warning of course which messed up my SEQUENCERS !!!)

It doesn't have to.

"[StageName].$JobStatus = 1 OR [StageName].$JobStatus = 2" on your custom trigger will absorb those warning messages just fine. Now if you hold the philosophy that there MUST be no warning messages...

Oh well.

-T.J.

roy · Post by **roy** » Sat Nov 01, 2003 4:47 pm

Hi,
the only thing that might help is if your job is successfull only if no real warnings occur;
this means that you can set the warning limit to the number of DB connections your job has (that generate the warning) and check for failed/Aborted status to know it failed, otherwise treat the job as successfull.

this is good only in cases when you want to proceed when the process/job had no real warnings except for the "doesn't support transaction" warnings

IHTH (I Hope This Helps)