Unconfigured Ad Widget
Collapse
Announcement
Collapse
No announcement yet.
RTVSQLSRC
Collapse
X
-
RTVSQLSRC
** This thread discusses the article: RTVSQLSRC **
"The RTVSQLSRC command can retrieve the SQL statements needed to create any file on the system, regardless of whether or not the file was originally created with SQL or DDS" . How can the cmd do what it claims to do ? ... ... nowhere I can find an SQL verb that mimics a DDS recordformat name. So the "SQL stmt to create any file" results ALWAYS in levelchecks for any created file that formerly existed on an AS400 or iSeries system. In other words, for our system, the "SQL stmt to create any file" creates ... useless files all the time Help !
-
RTVSQLSRC
** This thread discusses the article: RTVSQLSRC **
I think using DDS to create files is fine. But it seems as though the reliance on DDS is fading and learning to use a more global/portable data defnition language is a good choice. The goal of my article was to illustrate that you don't really give up anything by creating your files with SQL. Of course if you have multi-format files that require record format names, SQL will NOT support that one situation. Also, unless and until IBM comes up with an alternative to DDS for External Print Files, DDS is here to stay. -Bob
Comment
-
RTVSQLSRC
** This thread discusses the article: RTVSQLSRC **
The API allows you to retrieve the equivalent SQL for an existing database file, whether original created with SQL or DDS. That's all. The RUNSQLSTM command can be used to process the output from my RTVSQLSRC command; that is recreate the file using SQL statements. Will the file be identical to an existing file created with DDS? Sometimes, but not always. SQL after, as you've pointed out, does not support the concept of record format names. For database, record format names are somewhat useless in today's world (meaning new files should not be concerned with them). But legacy issue are always "issues" so that's to be expected.
Comment
-
RTVSQLSRC
** This thread discusses the article: RTVSQLSRC **
Advantages to SQL over DDS include: I) One stop shopping. Currently, what you can store in a single RUNSQLSTM member would require not only a DDS but a CL to create the file. Providing you use referential integrity and other constraints. Plain DDS is just 'too loose'. Not having the one stop shopping VERY often encourages developers to not use constraints.
Comment
-
RTVSQLSRC
** This thread discusses the article: RTVSQLSRC **
Advantates to DDS over SQL include: I) Field reference file. Although this can be mimicked quite easily with SQL. II) Having a record format name different from your file name. Frankly, the only time this is an issue is with the RPG compiler using Native access. I think it's time to change the compiler. Granted the compiler has work arounds, like RENAME. III) DDS allows the combination of a VIEW and an INDEX into a single object. Once again, only an issue if you use native access in a HLL. And that is only because the compiler checks the file at compilation time to ensure that it has the keys you mention. I wonder what it would take to have the compiler to just check to see if one of the Indexes has an acceptable access path?
Comment
-
RTVSQLSRC
** This thread discusses the article: RTVSQLSRC **
Why not use Operations Navigator? Under database you can generate SQL source for any file. While this is not the exact SQL script used to create the file, it will give you the required SQL code for files created both by SQL & DDS. Mark Harrison
Comment
-
RTVSQLSRC
** This thread discusses the article: RTVSQLSRC **
Hi We also had the same problem but after discussing with IBM they got it restored from one of the CDs. So I think you need to ask IBM to supply the same. Other option is to copy QSYSINC from machine having it to other machines , as these are only header files and have not chnaged since V5R1.
Comment
-
RTVSQLSRC
** This thread discusses the article: RTVSQLSRC **
If anyone actually wants to compile and use this tool that Bob has generously shared (Thanks, Bob), as opposed to just wondering out loud why you should or shouldn't, you'll want to change the two instances of two variables that have typos - nMsgLlvl to nMsgLvl (twice), and nSecLvl to nSevLvl (also twice). Now, If I may wonder aloud - does anyone know what the advantages or disadvantages are of the "system" proc vs. QCMDEXEC? Jim Rothwell
Comment
Comment