Focal Point
[CLOSED] Wut?!?... (Meaning of @0000013)

This topic can be found at:
https://forums.informationbuilders.com/eve/forums/a/tpc/f/7971057331/m/6097066016

October 05, 2011, 05:19 AM
Wep5622
[CLOSED] Wut?!?... (Meaning of @0000013)
Can anyone tell me what's meant with @0000013 in below error?
quote:
(FOC236) LINKED FILE DOES NOT HAVE A MATCHING KEY FIELD OR SEGMENT: @0000013


How am I supposed to know what that refers to?

This message has been edited. Last edited by: Kerry,


WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010
: Member of User Group Benelux :
October 05, 2011, 09:26 AM
Prarie
You need to concentrate is on the Focus Error - FOC236. You have a Join problem. Are these Focus Files? Are the join fields indexed?


In Focus since 1993. WebFOCUS 7.7.03 Win 2003
Joining Varchar fields?

- ABT


------------------------------------
WF Environment:
------------------------------------
Server/Client, ReportCaster, Dev Studio: 7.6.11
Resource Analyzer, Resource Governor, Library, Maintain, InfoAssist
OS: Windows Server 2003
Application/Web Server: Tomcat 5.5.25
Java: JDK 1.6.0_03
Authentication: LDAP, MRREALM Driver
Output: PDF, EXL2K, HTM

------------------------------------
Databases:
------------------------------------
Oracle 10g
DB2 (AS/400)
MSSQL Server 2005
Access/FoxPro
What I'm joining or what's wrong with the join, doesn't really matter to my question. I'm looking at the @000013 code that's giving me a rather unhelpful hint of where the problem is.

I think I found the issue with the joins. Apparently, even though according to the documentation XFOCUS format supports multi-column joins, it can't actually do them. I solved that by creating an artificial key from the combined fields, but I had hoped not to have to resort to kludges like that.

It would have been a major help if the error would be a little more indicative of where the problem was. I think the @000013 code is actually a relative line number counted from the first line in the first JOIN. If I go 12 (=13-1) lines down from there, I end up in the middle of above-mentioned multi-column join.

Unfortunately, with the built-in editor in combination with large amounts of joined TABLE FILEs, that does require some math to end up at the actual line number. Why do I have to do math to understand a message from a computer? It's much better at that than I am. Of course I can calculate an absolute line number based on an offset, but I shouldn't have to! It's silly.

It's a bit like you're at the cashier in a super market and she just blots out the prices of all articles and expects you to add them up yourself.

Computers are for convenience! Smiler


WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010
: Member of User Group Benelux :