Custom tables in dbdef

Use metadumptbl for each table on the test server.
Then use metaloadtbl for each table to load into the prod server.

THIS interests me.

When our custom Sales/Inventory system was written, it piggybacked off Lawson 5's framework.  Our databases, programs, error messaging, and tokens all utilize it.  LAWUNV simply sits on top of Lawson 9.1 libraries.

We did not, however, create a custom system code, and place the databases in dbdef.  But I was wondering if this could be the beginning of our 'modernization' effort.  We, of course, would lock ourselves into Lawson, in the future, as the majority of our user base accesses this custom system more than Lawson base - we only have about 150 using Portal.

As far as getting the 5v greenscreens migrated to 9.1, this may not be pratical.  But I imagined - somehow - the reports, like the databases, could be defined, and thus ported to the IFS, just as base Lawson reports.  Also, having the databases in dbdef might allow the user to utilize the new power-user product MASHUP, for better integration.  Furthermore, I would need to understand the upgrade process VERY well, as any db mods would need to follow this migration path.

Are there any other pitfalls, or hotspots I need to be concerned with here? 

Megan,  how long have you had custom databases in dbdef?  Do you have custom reports and screens that are part of the 'family' of objects that maintain these databases?  How about reports?

The reason I ask, is we have kicked the idea around a modernization project.  Ie, getting our custom susbsystem into Lawson with new system code SR, and enter (or upload) the custom databases into dbdef.  I am just thinking if it is practical, or even possible, and what the pitfalls, or barriers, as well as the upside could be.

We built our custom system using all the coding techniques, inclusive of error messaging and token mgmt, piggybacking off of Lawson 5 - way back when.  So, really, what conversion/migration, if it could be done, would be necessary.  At the very least, perhaps getting the databases defined in dbdef coupled with usage of the new power-user tool, MASHUP, for new custom programs would be our upside to the company.  Of course, I sound like I am outsourcing myself as a developer, but would this be a good modernization strategy?

Any thoughts, colleagues?

I have done this type of customization/architecture many times. It does give you a leg up on developing the app and integrating it with Lawson. For instance you can add drill around to your application with links to transactions interfaced to Lawson, etc. You should be careful that you keep it carved out of Lawson-delivered code as best you can to avoid conflicts with patches and upgrades. Assuming you do build within Lawson you can use portal, Excel addins, mashup designer, etc with your app.

On the other hand, given that you are essentially creating a new "greenfield" application there are two main strikes against this approach:
1) You are indeed locking into Lawson's environment, and need to be able to support it into the future, which may require training and retaining/procuring the appropriate internal or outsourcing resources.
2) There are a number of more-productive ways to build more-modern applications. =

Thanks for the prompt reply, John.  We appreciate it!