View Full Version : RTVSQLSRC
Guest.Visitor
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
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.
Guest.Visitor
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
iSeries Navigator will also show all the constrains and triggers associated with data files, not just DDL for the tables...
S.Mildenberger
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
You need option 13 of OS/400 installed - OS/400 - System Openness Includes. Scott Mildenberger
Guest.Visitor
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
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
Guest.Visitor
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
..with the fact that (I believe) they are not enhancing the DDS. It's easier to do lots of stuff with SQL. I don't like to get into the more complex database manipulation statements with it, as it is not always so easily intuitive or readily "maintainable". Cross-platform applicability is *big* in my book for both practical and career reasons. Besides, he's just providing a tool here, and as far as I'm concerned, a very useful one that will find many future applications.
Guest.Visitor
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
Guest.Visitor
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
I guess I broke the single-topic-per-thread law. :(
mpavlak
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
I have a machine at V5R1 and can see the library QSYSINC. My two other machines at V5R2 don't have these libraries? What gives and how do I get them so I can write the utility?
dchristie
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
These articles are always interesting and informative, but I must ask: What is the advantage of using SQL to create files over DDS?
markh@thorinc.com
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
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
robberendt
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
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.
robberendt
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
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?
robberendt
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
This article might be useful if you needed to do this in a batch method. However iSeries Navigator has a function to do this already for one shot deals.
luc.pittoors@abvv.be
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
"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 !
rjangelino@yahoo.com
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
Mike, Scott Mildenberger got it correct. You didn't complete loading all the CD's. Must have had on one of your famous loud Tie's and you missed that part in the install Doc's. Your friend, Bob A.
R.Cozzi
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
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
R.Cozzi
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
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.
R.Cozzi
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
We fixed the typos earlier today. When we posted the code, I gave it a once-over on lower/upper case consistency and apparently type two of the parameter names wrong. The code as posted in the article is correct.
MCWebsite.Staff
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
** This thread discusses the Content article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200)0
markkelley
12-31-1969, 06:33 PM
** This thread discusses the article: RTVSQLSRC (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=3200) **
Doesn't work for me. We are on V5R3 and the RPG compiles OK, but when I try to run the command, I get a empty member in the destination source pf. Here is the message detail I get:
RTVSQLSRC FILE(XXMKELLEY/DUMP) SRCFILE(XXMKELLEY/QSQLSRC)
Member DUMP added to file QSQLSRC in XXMKELLEY.
Member DUMP has no records.
Error found on STRSEU command.
Error found on STRSEU command????? Anybody else get this problem?
Powered by vBulletin® Version 4.1.5 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.