DSXchange

I'm completely lost on what you are trying to accomplish. You need to 'group' your data in order to get max values for anything other than the entire load. And if you need this max value on every record for the 'next stage', that sounds to me like two pass processing. First run through the data to g...

Krazykoolrohit wrote:see i need to calculate max of a column from a group of 20.

that means i need to pass rest 19 without any grouping.

That's different. So, you need a single value, the maximum value from this one field from all records processed? Then you need to just send that one field to the Aggregator.

Then assign it a value. You've got to tell it what column to do the First aggregation on, I'm assuming you've missed that step in the stage for all these columns.

Any chance you've used OCONV inside your target SQL?

Just exactly what it sounds like - take either the First or Last value for that field from any particular 'group'. You can get away with it if the value would be a constant across each group. Heck, you could even pull the MAX of that field as well, all would give the same result in that case.

Of course. You will need to group on the columns needed to support your MAX aggreegation. For the others, you either need to not pass them to the Aggregator or sometimes you can get away with setting them to 'Last' or 'First'.

Then you're probably not looking in the correct relevant folder.

Are you sure you haven't left it set to Account, for instance, and are looking for it in an external path? Or vice versa? I'm sure it's getting created, the question is where.

I wasn't implying I didn't understand what you meant. Just rolling my eyes at the early morning groaner.

Technically, part of what I meant when I said to 'completely uninstall' the client - sorry, should have specifically mentioned that.

That being said, what you posted was an Oracle error. So, in addition to what you've posted, please add in how you are handling the Oracle side of this - what kind of field you are targeting, stage used, if you are using custom sql, etc etc etc - fun stuff like that.

Next time, when you recognize the mistake before someone comes along and replies to it - delete the extra posts. They are your posts so you are allowed to edit and even delete them, but the delete can't happen once it has been replied to.

As noted, Something Else is going on as there are no prohibitions against hypens in any kind of string hashed file field.

Perhaps a constraint is not allowing those rows to be written?

As have we.

Not when it's overriden by TNS_ADMIN. It allows you to have one central place to store your tnsnames.ora and associated files, while maintaining multiple ORACLE_HOME values.

'as in swimming'?