infor.com
concierge
infor u
developer portal
Home
Groups
FACTS - Partner Community
Merging SMFLUP between versions of FACTS
salbritton
Does anyone know of procedures, or have a utility they would be willing to share, to assist with merging an SMFLUP that was generated on one version of FACTS onto a different version of FACTS? For example, if I developed a stand-alone application in version 7.5 and tag all meta entries with a mod ID, I can generate SMFLUP specifically for my mod ID. Now, I'd like to take that SMFLUP and install it onto a later (or previous) version of FACTS. I was always under the impression you could only merge SMFLUPs onto the same version.
Any advice is appreciated!
Brad Kraft
Forsythe Associates
bradk@fai-group.com
Find more posts tagged with
Comments
Eddy Vittini
Brad,
While Infor may take exception to my statement, I have always used the previous version's SMFLUP file to move mods to the newer release. For most (if not all) meta-data files the new fields that get added, are added to the end of the IOL of the file. So, the lst(iol(smprmt_74)) matches the lst(iol(smprmt_75)) upto the value in 74 and then the newer fields follow.
So, SMFLUP will match up the fields to the file and the whole IOL for the record should be present going to a higher release. For a lower release, it should "throw" away the extra fields since they will not be in the IOL of the file.
The ONLY caveat I would add, preserve the current release's SMFLUP file, since at 7.7 the SMFLUP key is over 200 characters, at 7.5 it was 120 (just a guess), but if you don't preserve the SMFLUP and make another SMFLUP at 7.5 using a SMFLUP file for 7.4 you may have issues losing records since the key is not big enough.
The other issue is at 7.7 the TAB screens are now part of SMPRMT and not built into the SMENTY/SMFMFM etc; so those need to be manipulated manually after installing the SMFLUP.
HTH
Bob Fitzgibbon
Proven Data Solutions, Inc.
skyler-williams
Bob Fitzgibbon's gave a good response. It cannot be emphasized enough to preserve the SMFLUP from the CURRENT (not live) release, that is, the release to which you are upgrading.
You CANNOT create the SMFLUP file on the old, e.g. f7.4, system and try to merge it into the new, e.g. f7.7 system.
When performing an upgrade the only way I was ever able to cleanly merge SMFLUP was to follow the procedure for the upgrade, i.e. copy to .MOD, copy .NEW to .SSI and to no extension, then merge the resultant SMFLUP file into the new system. I call this the test system. This SMFLUP file, although based on the new system's SMFLUP layout, is USELESS from this point on because of changes to be made in the test system.
With 7.7, I found that each SMPRMT record had to be individually addressed. Certain check boxes that had neither a "N" or "Y" in them had to be checked, unchecked, etc. until the record could finally be saved using the SMPRMT utility. Also, as Bob mentions, there is the issue of tab screens.
So, I get I get all the meta data just the way I want it, and make sure I'm on the latest incremental.
At this point on, I if ANY mods are made to the meta data on the old live system, e.g. f7.4, I MUST make them in my current f7.7 test system, too.
When finally ready to go live, I create an SMFLUP file on the current f7.7 test system. This is done by saying "YES" to creating the .MODS but NO to copying to .NEW and to no extension.
During the upgrade I do NOT try to convert the old. (e.g. f7.4), meta data mods. I get pristine FACTS f.77 meta data in .SSI and with no extension. Ideally these are done on the same incremental that the f7.7 SMFLUP was created. I know I've done this correctly because when I follow the instructions to create the .SSI files, it reports NO MODIFICATIONS FOUND.
Then, after the F1-Auto-update, I merge that SMFLUP. I copy that file from the test system to the new data/SM directory and simply merge it in. This way all the mods that were previously massaged and tested on the test system get incorporated into the new system.
This is the only way I know how to do it CLEANLY.
When done incorrectly, FACTS reports thousands of non-modified metadata records as mods. Been there, done that, and found out how to avoid it.
(hint, use UTLOOK to see how many records are in SMFLUP. If there are thousands, and you know you only have a few mods, don't use it.)
John Ford
Qualitech Computer Center
0712131256598360.doc
Important Links
Community Hubs
Discussion Forums
Groups
Community News
Popular Tags
ION Connect
ION Workflow
ION API Gateway
Syteline Development
CPQ Discussion Ask a Colleague
Infor Data Fabric
Infor Document Management (IDM)
LN Development
FAQs, How-To, and Best Practices
API Usage