|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
