DataStage

I had the mentioned error combined with a previous warning "When checking operator: When binding input interface field" "conversion with a nullable result". All the post on the internet lead to nothing. It turned out that I had a peek and changed nullability of several attributes in this and predecessor stages however apparently DS did not really do a good job. It displayed all nullable but not all were taken as such. The solution was to delete the peek and create it again...

Problem I used a joiner and was desperately looking for the attributes of the right input to propagate them to the output in the mapping tab but they where not there. Solution The joiner requires two thnigs not obvious to me: The attributes used to match the inputs must sport matching names! Attributes of the right joiner side you want to use in the output must NOT sport a name equal to one of the left side attributes!

Problem We call a DS job by its but DS does not seem to show even the request. Well, the caller gets an according message but other wise, Directory remains unmoved, logging does not seem to apply. Due to lack of permissions I could not double check it myself but I trust our DS admin. Causes a) Calling a sequence job with invocation id that does not allow multiple instances Well, yeah, DataStage does not allow that for whatever reason. b) Passing a parameter not specified to a (sequence) job Again, it seems picky to me. c) Not passing a parameter specified without default value to a (sequence) job I did not actually test this (yet), but it seems logic to me that DS must fail. Solution a) Remove the respective tick in the general tab of the job properties dialog (probable on the upper left corner). b) Remove the passing of the parameter (or define the parameter in the job properties and use it - there might be a reason that the parameter gets passed). c) Pass the para...

Historicisation is ancient history, really. I started with data-warehousing in 2001 and back then it was ancient history (no pun meant, would be lame anyway). No rocket science at all. Still it is a major topic in my daily life to date. I am very astonished no database has take on this topic so far, well no that I know of. I did not research just my own experience with Oracle, DB2 LUW and PostgreSQL. As a hobby, I implement such a framework for PostgreSQL (pre-alpha so far). Back to datastage. DataStage does provide at least two stage sets to tackle this but far from being a DS hotshot or even seasoned DS developer, I could not make to get run those Change Capture/Apply and Slowly Changing Dimension stage setup properly.

While debugging the other problems , I noticed the peek to output spaces for a char column even though the very same value written to the database was NULL. Surprising twist...

I had this experience with NULL and Change Capture stage . So I needed explicit NULL handling but stumble over another problem, well it rather is a problem of mine but I feel prone to forget about it, so maybe this post reminds me of it. I tried to set up NULL handling for a char(3) column by first converting the content of the column in a transformer stage using NullToEmpty() doing the change capture and reconverting the empty string to NULL before writing to the database. I was surprised to find the string '   ' instead of a null value in the database. You probably spotted the problem right away, but it took me some hours to get to wisdom over it however. The point is, that char columns can be NULL but there is no emptiness. By definition a char is a string right padded to its length with space characters... So I reformed the replacement by some very unlikely i. e. three non-printable characters like bell,  device control three, negative acknowledgement. However, my ...

Well, I just adapted a job where the Change Capture stage is being used. My test data contain NULL as values to be compared against. I was very much surprised that the comparison with NULL results in finding no difference even though - to the best of my knowledge - SQL standard requires that such comparison always return non-equality. I know, DataStage is no SQL database but then again it is a tool heavily (I suspect mainly) being used in connection with SQL databases (at least as of writing this) and thus it would have been nice and straight forward if it followed the SQL standard where applicable. Please let me know if your experience is with respect to Change Capture stage and NULL is different. My observation is that counter-intuitive to me, that it make me unsure whether I misinterpreted the results.