robert fuschetto Posted October 21, 2021 Share Posted October 21, 2021 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 Detail: (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 More sharing options...
Martin Yergeau Posted October 21, 2021 Share Posted October 21, 2021 robertf: TBLMSTR_PMTSSMRY 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 More sharing options...
robert fuschetto Posted October 21, 2021 Author Share Posted October 21, 2021 But why is it not an issue in DEV or TESTonly PROD Link to comment Share on other sites More sharing options...
robert fuschetto Posted October 21, 2021 Author Share Posted October 21, 2021 and i have no access to to echo in prod. Link to comment Share on other sites More sharing options...
Martin Yergeau Posted October 21, 2021 Share Posted October 21, 2021 robertf: But why is it not an issue in DEV or TESTonly PROD This seems to be a version issue Link to comment Share on other sites More sharing options...
robert fuschetto Posted October 21, 2021 Author Share Posted October 21, 2021 there seem to be a lot of those! Thanks! Link to comment Share on other sites More sharing options...
john cullen Posted October 21, 2021 Share Posted October 21, 2021 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 More sharing options...
robert fuschetto Posted October 21, 2021 Author Share Posted October 21, 2021 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 More sharing options...
robert fuschetto Posted October 21, 2021 Author Share Posted October 21, 2021 So our tech folks are trying to find out if the SQL versions differ. If not that perhaps it is some sort of incompatibility between WF versions. As mentioned above. I removed the column RPTBANBR, I left the column IDXBA2 (recall it was a master file define set to the RPTBANBR)now it works! Link to comment Share on other sites More sharing options...
Martin Yergeau Posted October 21, 2021 Share Posted October 21, 2021 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 More sharing options...
Toby Mills Posted October 21, 2021 Share Posted October 21, 2021 Its funny how things recur in the world of WebFOCUS. Heres an older post from Focal Point with a similar sounding Upward Compatibility (UC) issue: [sharing] Curious Little Bug Introduced by 7.7.04 Link to comment Share on other sites More sharing options...
robert fuschetto Posted October 22, 2021 Author Share Posted October 22, 2021 I did find out our versions of SQL are the SAME across all 3 platforms. So does this then confirm the issue has more to do with whatever WF 8206 is doing with the code vs 8207especially since it works fine in TEST/DEV which are on 8207 v28 and 8207v27 respectively. Link to comment Share on other sites More sharing options...
Martin Yergeau Posted October 22, 2021 Share Posted October 22, 2021 robertf: So does this then confirm the issue has more to do with whatever WF 8206 Seems to be the case Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now