May be QSQGNDDL did not translate everything.
Did you try to do a reverse ingeneering with the client Access or ACS wizard
or the GENERATE_SQL stored procedure (to get the CREATE OR REPLACE TABLE
statement).
Did you get any comment in the script that something is not supported?
Just modify the script and run the CREATE OR REPLACE statement. I never had
any problems with this method. But agreed I'm not sure whether these
physical files/tables included varying length fields.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
?Train people well enough so they can leave, treat them well enough so they
don't want to.? (Richard Branson)
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Troy
Hyde
Sent: Mittwoch, 18. Oktober 2017 03:54
To: midrange-l@xxxxxxxxxxxx
Subject: DDS vs DDL. Record format level
I've got a handful of DDS physical files, some that have existed since the
late 80s, that I'm converting to DDL. I'm generating the DDL using QSQGNDDL
and creating the new SQL tables.
It's important that the record format level does not change between the
existing physical file and the new SQL table because of the number of RPG
programs compiled against the existing level of file.
I have done this countless times in the past but am running into a snag
tonight. Fields defined as varlen in the DDS, and as varchar in the SQL are
resulting in a record format level change. I have been able to prove that
it's the varlen/varchar fields by removing those fields from both the DDS
and DDL and the resulting levels match. However, any time I add one or more
varchar, the levels change.
I've tried numerous options including null, not null, allocate(0) and it
doesn't make a difference.
The record lengths match between the file and the table. The record format
names match. The field names/positions/lengths/attributes all match.
Using DSPFFD, the DDS file shows the variable length field like this:
SVMODL CHAR 40 42 147 Both SVMODL
Field text . . . . . . . . . . . . . . . : VEHICLE MODEL
Variable length field -- Allocated length : None
Coded Character Set Identifier . . . . . : 37
while the table looks like this:
SVMODL CHAR 40 42 147 Both SVMODL
Field text . . . . . . . . . . . . . . . : VEHICLE MODEL
Variable length field -- Allocated length : None
Default value . . . . . . . . . . . . . . :
''
Coded Character Set Identifier . . . . . : 37
I believe I can set the new tables' record format level checking to *no
since for all intents and purposes the files ARE identical. But that goes
against every programming reflex I've developed.
Any thoughts or suggestions?
Thanks.
TROY HYDE, Upgrades and Standards Manager
FLEX : 800 262 3539
Troy.Hyde@xxxxxxxxxxx
Confidentiality Notice: This communication and any associated attachments is
intended only for the person or entity to which it is addressed and may
contain information that is privileged, confidential or otherwise protected
from disclosure. Dissemination, distribution or copying of this
communication and any accompanying attached information by anyone other than
the intended recipient(s), or an employee or agent acting on behalf of the
intended recipient, is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to this
message, and then delete it from your computer.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
midrange.com
