Jump to content

I guess this should be a versioning thing. I get confused bu...

robert fuschetto

Recommended Posts

I guess this should be a versioning thing. I get confused but they tell me DEV is on 8207v28, TEST is on 8207v27 and PROD is on 8206. We have been stuck like thisupgraded to v27, too many issues, waited forv28now testing. Anywaydevelopment cant stop and we have been doing so spanning v27/v28; creating content in v27/v28 and moving to PRD without issue. Just basic stuff.

Anyway, the HTML page runs fin in DEV and open for editing fine in DEV.

It runs fine in TEST buts will not open for editing in TEST!

When ported to PROD it immediately errors out.

It is using two fields recently defined for a master file, also ported to PROD.

An error has occurred


(FOC1400) SQLCODE IS 169 (HEX: 000000A9) XOPEN: 42000 (FOC1500) : Microsoft OLE DB Provider for SQL Server: [42000] A column has been (FOC1500) : specified more than once in the order by list. Columns in the order by (FOC1500) : list must be unique. [42000] Statement(s) could not be prepared. [] (FOC1500) : Deferred prepare could not be completed. L (FOC1406) SQL OPEN CURSOR ERROR. : TBLMSTR_PMTSSMRY

Link to comment
Share on other sites






Looks like you are referencing twice (or more) the above field or the way you may have use it (BY, SUM, PRINT, DEFINE, COMPUTE) makes WF to include it at least two time and the generated SQL is wrong.

Take a look at the code generated, you will probably find where is the issue using -SET &ECHO = ALL

Link to comment
Share on other sites

FOC1400 is the generic error number for a SQL error. Meaning, this is a SQL error. And the SQL error is the return code from sql, 169. which basically means a duplicate column is in your request.

I am willing to bet your SQL version on PROD is different than you SQL version in DEV, UAT.

which would explain why it runs one place not another.

I would open the .fex in DEV and look for a duplicate column name in the focexec request and remove it.

probably an inadvertant duplicate BY field.

Link to comment
Share on other sites

I can have our guys check that. Interstingly, there is no explicit column duplication. There is however a column called RPTBANBR. In the master we have a define item: IDXBA2 = RPTNANBR. Its a long story! Anyway I have BOTH of these in the BY. I am removing one and sending apackage to production with the hope that it resolves the issue.

I will also check on teh SQl versions.

Link to comment
Share on other sites

Since IDXBA2 is a DEFINEd field in the master file only and does not exist in the table itself, WF has to also include the original field (RPTBANBR) to be able to define IDXBA2 resulting of having twice the same field with in the generated SQL.

So, be removing one of them, you fix the problem.

But the problem is also related to WF version where in your 8206, SQL translator cannot manage twice the same field.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...