DSXchange

Hi All, Does anyone know of ODBC driver for SQL Server that is for alpha true 64 bit? oh and if not, any thoughts of getting data from it, it is my source data? (I have some Ideas like unloading and ftp the file to my DS server) any info would help! Thanks in advance, It was my understanding that A...

Hi Ram, This depends how your project is designed. The main issue somes with the Sequencers. You need to build/edit those sequencers again. We never tried this before ( renaing with script on export file).. I suggest to go manually and replace the names with convensional names. Tnks Neena I have ju...

All, We are going through an effort to clean up our DataStage environment before undertaking our next big development push and one of our issues is that everyone interpreted our naming standards differently :o. We would like to go through and rename these jobs to follow our naming standards. We have...

More like: Flat file (EBCDIC) -> Split -> 4 Shared Containers -> Combiner -> SQL Server (FAILED) Flat file (EBCDIC) -> Split -> 4 Shared Containers -> Combiner -> Transform -> Flat File & SQL Server (WORKED) Flat file (EBCDIC) -> Split -> 4 Shared Containers -> Combiner -> Transform -> SQL Serve...

I have logged a Trouble Ticket with Ascential on this one but was wondering if there is anything else that I might try: We are having strange issues with the SQL Server bulk load stage after 7 upgrade. We have several jobs that we used in a previous POC that worked correctly. These are pretty simple...

Thanks Manoj, But I am not using the cast function anywhere. Actually the data type for the field in the source text file is also varchar(120). I'm just doing a direct load. The source text file contains exact data (and data type) from the target SQL DB (loaded from the SQL DB in another job). Also...

Skip using a hash file. Simply have each job produce a sequential text file as its output. Make sure all jobs produce exactly the same format. Then, just concatenate them together using a command stage issuing a copy statement (search the forum, this is covered a lot). Now you have a single load fi...

I don't do SQL Server - but I think your answer is pretty well spelled out in the error message. You are hitting a per-user or per-process threshold. If you can't throttle the number of loads back, have an admin adjust (ie, increase) whatever limits you are slamming into. It may also be a license l...

I agree with Vincent bringing in a good consultant is the way to go. We had the same issues here with the developers (including myself) having to go from a stored procedure and Perl solution mindset to an ETL one. It only took a couple of weeks to get up to speed with a help of a consultant to get a...

Well, we finally figured it out with the help of the profiler. single quotes are required so that the code will be: sch_yr = RIGHT('#Param_1#',4) I thought we had tried everything including single and double quotes but evidently not. Thanks again. If Ascential would pass the real error messages bac...

:oops: :oops: :oops: :oops: Okay, I spoke a little too soon. The Direct read does not seem to pass parameters back to the database. So, basically I still need help! Since the errors coming via the oledb stage can be misleading (it does not return the error coming from SQL Server) I would recommend ...

No they wont. Just becuse a column comes into a transform does not mean that there has to go out of the transform. Do you even have a transform stage in the Job? If you do not have a transfrom stage in the middle then you should.

You have two options, one if it is a flat file that you are sourcing from. :arrow: If you are pulling directly from a table then don't include those columns in the select from the source stage. :arrow: The other option is to add the columns to the source side of the transform and don't map them to a...

I am not sure about Trial and Error. You just need to make sure that the case evaluates in a manner where the most specific evaluation is first then through the other cases. In other words if multiple cases evaluate to true for a specific condition make sure that the correct one comes first in the c...

CASE statements are top-down. The first to evaluate to @TRUE exits the construct. So, put them in priority order. I agree, case statements are top down. :D If they were not, modifying the script in this manner would result in a concatinated string of all the cases that evaluated to true. :shock: