Custom tables in dbdef

Sort:
You are not authorized to post a reply.
Author
Messages
MeganS
New Member
Posts: 1
New Member
    We've copied our production product line over to our test server using dbcopy.  We have a custom system code that we use for payroll.  All of the programs (including the custom programs) copied over just fine, but the table files were not copied over to dbdef.  The custom system code itself exists in dbdef, but there are no files attached to it.  We restored the test db for this productline from a backup of production, so all of the tables themselves do exist in the database.  Is there a quick way to get these files copied over into dbdef on the test productline without having to manually add them one by one?
    John Henley
    Senior Member
    Posts: 3348
    Senior Member
      Use metadumptbl for each table on the test server.
      Then use metaloadtbl for each table to load into the prod server.

      Thanks for using the LawsonGuru.com forums!
      John
      Mark F. Hardy
      Veteran Member
      Posts: 44
      Veteran Member
        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? 
        Mark F. Hardy
        Veteran Member
        Posts: 44
        Veteran Member
          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?
          John Henley
          Senior Member
          Posts: 3348
          Senior Member
            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 using the LawsonGuru.com forums!
            John
            Mark F. Hardy
            Veteran Member
            Posts: 44
            Veteran Member
              Thanks for the prompt reply, John.  We appreciate it!
              You are not authorized to post a reply.