DSXchange

Welcome. Please look at your DS installation CD and run thru the tutorial exercises. Your example indicates you are trying to learn DS from the very beginning. The tutorial is the best method, as it has pictures and exercises that take you thru the fundamentals of building hash lookups, references, ...

russ356 wrote:I know people must think I am crazy or un-educated in Ascential

We've all been there...think of the Inner Circle as your therapy group.

The OCI stage automatically puts a TO_DATE() on DATE datatype columns and your dates HAVE TO BE IN THE STRING FORM OF YYYY-MM-DD or YYYY-MM-DD HH24:MI:SS. So, why do you want to make things not work right and prolong this post? If you want your answer, even if it's not what you need to do, just use ...

Ahhh, the value of posting the exact WHOLE error message. Your message is coming from the ODBC driver, so therefore, it's data related and it's your RDBMS stage that is having the issue. I suggest you investigate your source data and identify which column is having the issue. Maybe you concentrate o...

Have you tried just a single line of data in the source file and see if the job runs successfully? If the data doesn't matter, and it's always the first line of data in the file that has an issue, maybe there's a buried low/high-ASCII character buried at the beginning of the file. Try a fresh text f...

What environment variables are you talking about? DS jobs run under the environment variables in the ~dsengine/dsenv file. When jobs shell to run OS commands, the commands execute under that environment. What more do you need?

You are using the Sequential file stage? What is the file type, delimited or fixed? Is the file set to DOS or Unix or Other? If the first row of a file always has an issue, no matter what row is in the file, then there's got to be something with your file configuration.

I read your post 3 times and I still can't figure out the exact problem you are stating. If you move the row in question to the end of the file, does that moved row load, or does the new first row now have the issue and the moved row is now fine? If you remove the row from the file, does the file lo...

Ray, It will cost about 675,000 for EE and 230,000 for Sever edition. Do you think is it worth to pay so much more for EE? If what you need is a space shuttle, why look at airplanes? If your requirement is to process billions of rows of data, you have a large hardware budget allowing carte blanche ...

The first help is to point out you are posting in the wrong forum. (editor's note: Topic has now been relocated) The second help is to suggest putting a constraint in place in a transformer to throw away any rows that have a blank value where one isn't allowed. You can't really avoid reading those r...

I'm not going to cover the differences, that you can read from the 4 years of posts talking about them. I'll answer why someone would build a server job in an environment where only parallel jobs were built. Server jobs are extremely flexible, don't require a lot of thinking to build. The Server sid...

What Craig was asking is to define what the integer format should look like. Should it be YYYYMMDD, or MMDDYYYY, padding with zeroes, what? Should it be the integer number of days since a given start date, what does integer(10) mean? That's not a common term for describing a date without delimiters.

Twiddle the setting on the Incomplete column in the column definitions of the sequential stage to Replace or Retain. If replace, you can give it default text. In the transformer constraint, look for your replacement text in the final columns to pick out the incomplete rows.

For each source dimension table extract out of Oracle and landed to two sequential files, one the full column set, the other just your natural keys. For your fact tables, create a sequential file of natural keys for each foreign key dimension lookup required. Execute a sort distinct on the concatena...

Your reference lookups are against all 12 million rows? Are these dimensions? Why are you dumping the whole table to a hash file, why not just get the rows you need? If you took all of the distinct natural keys for each dimension in a typical run, I bet you would only require a vastly smaller number...