DSXchange

What 'above thing' are you actually asking about? I don't see anything like a question or specific issue that you are having.

1. Can you be more specific about the 'reordering' needed? What did the posts say need to come first/last? I suspect you may need a 'lib32' in there somewhere.

2. Just like in Server, except you have no Folder stage. Feed from the Sequential File stage instead.

Or have a chat with your DBA.

I don't see any 'issue' yet... have you tried it?

Ugh... LONGs.

If this error is specific to you, and the patch doesn't help, try a complete reinstall of the client software.

Never mind the fact that processes can be handed around from CPU to CPU like hot potatoes. :D Have a chat with your Sys Admin types, they should be able to explain what information you can or can't get from your system.

Search the forums for the error, this has been solved before. Permissions problem, from what I recall.

A little lost... So, you're not using the hashed file to 'aggregate' or 'de-dup' the data, it is the actual target of these jobs? Meaning, the goal is to build these hashed files, yes, not use them in some intermediate fashion? And you have like data from three different tables being collected befor...

You would need to create a VOC record for each of these hashed files, that is what is missing when you don't create them in an 'account'. Plenty of discussion here on the subject, but here's some quick syntax: SETFILE <full hashed path> <name> OVERWRITTING The <name> would be what you would referenc...

And here I thought parsimonious meant something that smelled like parsimmons.

You need a combination of IConv and OConv for the date portion, no clue how you are going to handle the time:


Off the cuff.

The table is indexed for the some of the columns and not to all the columns. 'Some' of the columns can be ok as long as the columns you are using in your update statement are on the leading edge of the index - i.e. are the first columns in a compound index. Otherwise, it cannot be used and we're ba...

There are better ways to... well, never mind. Actually, on the issue of comparing dates, that is a fundamental technique - convert to internal format and then directly compare the internal values. So that part is fine. And you don't have an issue 'returning @TRUE/FALSE' you just have an issue with y...

Willing to post your routine code?