Tweet
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
** This thread discusses the Content article: TechTip: SQLCOD End-of-File Gotcha0
** This thread discusses the Content article: TechTip: SQLCOD End-of-File Gotcha0
-
-
TechTip: SQLCOD End-of-File Gotcha
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
Nice work. I have seen and cleaned up code similar to that in your example. My personal opinion is that it's just sloppy code. Its those same people (you know who you are!) that don't check to make sure a CHAIN opcode completed successfully before using the data in the file fields. The reasoning: "The record will always exist. The whole system is built that way." Or some other such twaddle. It might be true but there's always the oddball circumstances such as the user who knows how to use DFU!. The is no such thing as "always" in software development. Just my humble opinion. :-) Jeff Olen Olen Business Consulting, Inc. Email: jmo@olen-inc.com Phone: 760.703.5149 Web: www.olen-inc.com -
TechTip: SQLCOD End-of-File Gotcha
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
Great article meant to get us thinking about the many sharp edges in our development environment. SQL is a powerful data language that IBM has made easily accessible from RPG. But like the article states, there is so much more than BOF/EOF. A lot of times, I use STRSQL to test my SQL cursor definitions. However, inside RPG the SQLDA provides a rich set of codes to let the program know what's going on. IBM has done a great job listing and categorizing these codes. Go to the iSeries information center and do the following search: "iseries sql messages and codes" (include the double quotes)Comment
-
TechTip: SQLCOD End-of-File Gotcha
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
Jeff, I'd like to take a moment to thank you for your input to the forums but at the same time to use your comment as a little bit of a "style guide" if you will. I hope no offense is taken! Anyway, while I understand your opinion about the issue of not checking for CHAIN, I know plenty of shops where there are standards in place (either understood or even in some cases written) where master file records are assumed to exist. But I'm not arguing the merits of that approach, I just want to point out one little thing: you use the term "sloppy coding" and then dismiss the argument for it as "some other such twaddle". There are shops that use that sort of programming all the time, and to someone who has been brought up that way, being told their programming technique is sloppy and their thinking twaddly might be a bit harsh. Instead, simply point out the weakness and call it what it is: a bad programming technique. Leave out the editorial name-calling. And this isn't me trying to be the Politically Correct Police, either: I appreciate your position (and I even agree to a large part). It's just that it's easier to get a reasoned response if words like "twaddle" stay out of the mix. Again, I appreciate your input and I hope you don't take this as calling you on the carpet. I just noticed it because it's similar to comments I might have written (I'm quite certain I have used the phrase "some such twaddle" in the past) before I was charged with trying to keep the forum a kindler, gentler place. http://www.mcpressonline.com/mc?.6b506c7a Joe Comment
-
TechTip: SQLCOD End-of-File Gotcha
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
CodeComment
-
TechTip: SQLCOD End-of-File Gotcha
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
I've heard more than one person recommend using SQLSTT rather than SQLCOD; it seems to be a bit more detailed. I do agree about your issue with SQL in general, though. Jeff noted about how DFU couild get a master file out of synch; just imagine what havoc would be wreaked on SQL processing if the database was out of whack! The whole notion of set-based processing DEMANDS that your database always be in tip-top condition, lest you miss processing rows because a master file record is unavailable. JoeComment
-
TechTip: SQLCOD End-of-File Gotcha
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
Joe, You are probably right. I can only plead temporary crankiness. It was late when I was writing the post and I had actually spent the better part of the day yesterday cleaning up some old code that was riddled with "less than desirable coding practices".I'll be more politically correct in the future. I just want to say that the comments were meant in a more tongue in cheek manner and I am sorry if anyone was offended. Jeff Olen Olen Business Consulting, Inc. Email: jmo@olen-inc.com Phone: 760.703.5149 Web: www.olen-inc.com Comment
-
TechTip: SQLCOD End-of-File Gotcha
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
Thanks for your understanding, Jeff. Really, I don't want to be the PC Police. It's just a sort of "kinder, gentler" thing. There are forums that shall remain nameless where "RTFM!" is a regular refrain, and I find that offensive, especially as we try to bring in newcomers. Your comment was nowhere near that level of nastiness, but at the risk of seeming a little over-protective, I thought I'd bring it up now rather than later. As to "less than desirable coding practices" I know what you mean. I especially hate it when I find them in my OWN old code. But I have a special code word now: I call it "clever coding", in which "clever" is short for "unreadable, undocumented and unlikely to be maintained by anybody but the original programmer who has long since moved on." 
Joe
Comment
-
TechTip: SQLCOD End-of-File Gotcha
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
I've heard more than one person recommend using SQLSTT rather than SQLCOD; it seems to be a bit more detailed Contrary SQLCODE is more specific. There may be a 1:n relation between SQLCODE and SQLSTATE, i.e. for a single SQLSTATE several SQLCODES could be returned. Example: SQLState 22003 A numeric value is out of range. Corresponds to: SQLCODE: -302 Conversion error on host variable or parameter &2. -304 Conversion error in assignment to host variable &2. -406 Conversion error on assignment to column &2. -446 Conversion error in assignment of argument &2. -802 Data conversion or data mapping error. or: SQLSTATE 22007 An invalid datetime format was detected; that is, an invalid string representation or value was specified. Corresponds to SQLCODE: -180 Syntax of date, time, or timestamp value not valid. -181 Value in date, time, or timestamp string not valid. SQLSTATE should be used when developing for cross platform or using several database (even other than DB2) BirgittaComment
-
TechTip: SQLCOD End-of-File Gotcha
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
Joe, is there a list of SQLCOD's. Like your example -181. I have a list of SQLSTATE's with the SQLCOD to the side but no explanation to what the SQLCOD means. Thanks Bruce "Hoss" CollinsComment
-
TechTip: SQLCOD End-of-File Gotcha
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
The SQLCOD number usually maps to a message ID. Try this: dspmsgd sql0181 qsqlmsg ChrisComment
-
TechTip: SQLCOD End-of-File Gotcha
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
Normally, I code my SQL processing by checking that SQLCOD >= 0 and that SQLCOD <> 100. This indicates success (ignore warnings). Then, I check for SQLCOD < 0, indicating failure. Finally, I check for SQLCOD = 100, row not found condition. If I am expecting to handle certain types of failures, I will put those tests in as well. All the while I never embed that hard coded magic numbers like 100, but rather use a /copy book containing all reasonable and prudent, commonly used SQLCOD values, which is shared at an enterprise-level. We have codes like ROW_NOT_FOUND = 100, CURSOR_NOT_OPEN = -501, TABLE_NOT_FOUND = -204 and so on. As more and more common codes are needed, the copy book is updated and all programmers benefit. In addition if in the scary event that IBM decides to change some codes around, the one copy book is changed and all programs are updated accordingly when recompiled through Turnover.Comment
-
TechTip: SQLCOD End-of-File Gotcha
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
Thanks, Birgitta! That's what I get for taking someone's word for something. I read in a mailing list post back in 2004 that SQLSTT could map to more than one SQLCOD, and I blindly believed it. Silly me. It *is* true that SQLCOD may change because it's DB2 specific and SQLSTT is more industry standard. Also, I understand that the first two digits of the SQLSTT can be used to determine if the data is okay; 00 or 01 is okay, 02 is EOF, anything else is an error. It's interesting. I wonder if you should code you standard logic to use SQLSTT for platform independence, and then have a DB2-specific error routine that uses SQLCOD? Joe Comment
-
TechTip: SQLCOD End-of-File Gotcha
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
I like this technique, Chris. It's like the Unix API errors. DSPMSGD CPEnnnn, where nnnn is the Unix error. JoeComment
-
TechTip: SQLCOD End-of-File Gotcha
** This thread discusses the article: TechTip: SQLCOD End-of-File Gotcha **
You can find SQLCOD in: http://publib.boulder.ibm.com/iserie...zalafinder.htm This link is for V5R2Comment
Comment