Thanks so much for this. I hadn't heard about the deprecated commands yet, so that tip is sure to be helpful. I'll look up Thomas Maul's Summit session, too. Thanks.
Doug On Thu, Sep 1, 2016 at 9:44 AM, Myriad List <[email protected]> wrote: > > From: Doug Hall <[email protected]> > > To: 4D iNug Technical <[email protected]> > > Subject: Upgrading 2004 to v15 > > RE: Should I shoot for an interim version, say v13, or is > it possible (practical) to go all the way from 2004 to v15? > > Doug; > > Definitely do not bother with incremental version upgrading unless you are > in version 2003 or before and then all you need do is convert to 2004 and > then straight to v15. v15 is much better at the conversion and properly > auto populates the new primary keys. While I don’t recall which versions, > some earlier versions (v13 - v14?) had an issue where updating the final > datafile did not populate and save the new keys so you had to write code to > fill them in. v15 handles this very fast. > > v2004 has a unique checkbox when running 4D Tools Repair Structure > “Rebuild all forms”. You must do this with 2004 Tools or many of your > forms will function like static pictures of what once were tab-able > objects. I’m not going to get into why other than make sure you do this or > you will be starting over in 2004 or rewriting lots of forms later. > > I have done quite a few from 2004 to v15 and the process can be fairly > simple to complex depending on: > > - plugins used > - web application situation (some such as contextual have to be completely > re-written) > - how many deprecated commands you have used > - how many deprecated objects such as “linked arrays” you have on forms > - how far back in the 4D family your application originated (just more > issues) > apps written in 2004 and later will convert quicker and easier > than apps that originated in v1.04 > > Consider this before you get in too deep: > > - Read the all 4D upgrade documents carefully as much is covered there > > - Reach out to Bob Miller with Parker Hannifin as he did a session at the > 4D 2016 Summit that went into great detail on "Upgrade Phobia". No sense > in covering what has all been so adequately done. Most applications will > be affected by a small fraction of all the upgrading issues so do not be > discouraged by all the possibilities. Its not that difficult unless you > start converting before you digest the relevant material and have to re-do > your work (which I did several times by the way) > > - Try to Locate Thomas Maul’s summit session documents on conversions > (2014 ? 2015? I don’t recall) . He too had some helpful material. > > Maybe your 4D sales rep will help you obtain these docs as I’m > sure they would be happy if you upgraded. I’m not sure how publicly > available they are. They cover the nuances and hindsight that the 4D docs > don’t have. > > Some hindsight information I picked up: > > The consensus of deprecated commands that are replaced with __o__ seems to > be leave them alone for now rather than globally replacing them (unless you > have lots of extra time for the conversion). There is code out there that > will go through your methods and update them all but the thought was you > will lose track of where all these instances were. The application will > run as is because the commands still function. This allows you to later go > through the code and replace them making sure there are no unintended > consequences. An example of that would be if you relied on set string > lengths of variables to control input. C_string(12;…) will now function as > C_TEXT(), so your converted app may have some string bugs but it will run. > > Note that much has already been said about Primary Keys so I’m only going > to touch on summary of what I took away. > > - UUID or LI is a personal preference - both work fine > - UUID would be better for syncing with outside data sources > - LI is a bit faster/smaller and more “human readable” if you have to pick > through any data some day > - Its always safe to simply let 4D create a new ID field (your preference > UUID or LI) > - Some developers with legacy applications decided to use these primary > keys only for 4Ds journaling and leave their legacy key systems in place. > Let 4D create keys for all tables just to allow the new 4D journaling. Its > fast and datafile space is cheap these days. > - If you have an obvious field that is unique and can function as a LI key > it is certainly safe to use it. > > John Bernhoft > Myriad Systems LLC > > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: http://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** > ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
