DSXchange

You still have not fixed the other system tables (and you're really lucky that simply moving UV.ACCOUNT worked at all).

Search the forum for VERIFY.SQL, which you will need to repair the system tables such as UV_SCHEMA, UV_USERS, UV_TABLES, UV_ASSOC, UV_VIEWS, UV_COLUMNS.

Use the uniq command. Dump the contents of the Data Set using orchadmin command, and pipe its output into a uniq command.

Not enough information. Please compare the complete set of NLS environment variables for DEV and PRD.

Did you create the record schema manually?

If not, you seem to have uncovered a bug, which you should report to your official support provider.

Copy folders is not the correct mechanism. This does not handle the "system tables" such as UV.ACCOUNT, UV_SCHEMA and others. The right way is to export from the old system, create new projects on the new system, and import on the new system. Are you still able to export from the old syste...

There should be no requirement to clear the partitioning. What specific stage type is the target?

Temporarily change the value of $APT_CONFIG_FILE to a real configuration file pathname, adjust your node pool settings, etc., then switch back to $PROJDEF.

You only get that warning in the data viewer. $PROJDEF can be replaced when the job runs, but (in your version) the data browser does not have that capability.

Can you post the SQL statement? It does not matter if any constants in the SQL statement are Chinese.

A simple If..Then..Else to check for "00000" should fix it. The Else clause contains your Trim() function. The Then clause simply returns "0".

Surely the SQL statement mentions the column(s) involved?

adityavinay wrote:I faced the same issue but with teradata. I changed NLS to ASCL_ISO8859-1 instead of (UTF-8) and it worked...

Can you explain why it worked?
Can you be sure that it is a generic fix, or just a workaround?
Are you aware that there are 12 parts to ISO8859 ?

This time I think you are incorrect. I further think that the LF was found at position 205, and there's a CR at position 204.

Actually I'm not sure that's available in version 8.1. It's definitely there in version 8.5 and 8.7.

Without doing the research it makes sense to me - an immediate determination of failure of the first operation is needed to be able to begin the alternate operation.