Question Data Dictionary Vs Df Scripts

[catch.saravana]

I am sure many would have come across this scenario but I would like to know the reason for the same. Let's consider sports db; I tried creating a field on customer table (could be on any) with a field name starting with '_' (underscore) and progress throws an error saying 'A valid PROGRESS identifier must start with a letter. Please enter another name.'. But if I try loading the same field (starting with _) through DF, progress loads it successfully and am able to see the field on the table [Admin > Load Data & Definitions > Data Definitions (.df file)]. Why?

How did I encounter this and why I need to know? >>> Our current application is on 9.1E and they have _userid field on 6 non VST tables. I know its a bad design but it's too late to suggest. The worst part is there are 29 occurrences of the below code on the code base;

find _user of {&buffer}. >>> where &buffer is one of those 6 non VST tables

On 9.1E _user table has got P/U index on _userid field but now on 11.6 it has got unique index on _userid + _domain-name which causes code issues and I will have to refactor the code.

Is there any code migration document available?

 

[TomBascom]

Such a field may, or may not, be an actual problem in 11.6 -- it isn't something that I have tested.

BUT

You're playing with fire. Progress reserves table and field names that start with "_" for its own use.

OF is one of those "just because you can does not mean that you should" keywords. Yes, it is in the language. It made a good demo in 1987. It has been making inscrutable code ever since. Replace it with a proper WHERE clause whenever you find it.

It should be a fairly simple search and replace to fix a mere 29 references against only 6 tables. If you cannot think of a better field name I would change _userid to zuserid. That is how I would mitigate it. Do it now. Before it becomes a bigger problem.

Keep in mind -- programmers *always* find the worst possible example in your code base and they will use it as the template for appalling insanity. And then claim that they were "just following best practices as embodied in the code".

 

[Rob Fitzpatrick]

One point to be aware of is that since 11.0, which added multi-tenant capability, you can no longer have an "@" in a username as it is now the delimiter between the username and domain name (domain names are used when multi-tenancy is enabled).

Also, I agree that you should never have programs or schema objects whose names begin with "_". Lots of Progress code assumes that such things are Progress-provided, not part of your application.

I'm sure if you search the KB you can find articles on migrating from v9 or v10 to v11.

 

[catch.saravana]

@TomBascom @Rob Fitzpatrick - Thanks for the details!

It should be a fairly simple search and replace to fix a mere 29 references against only 6 tables.

Sorry Tom if I haven't conveyed it properly. I meant that kind of statement (find _user of {&buffer}.) has 29 occurrences but there are roughly 600+ references to _userid on the code base (which involves so much coding and testing).

As you pointed out I will rename the field and make changes accordingly as part of migration; better to have it fixed.

 

[ForEachInvoiceDelete]

Rob,

Found that out the hard way as we use email address's for usernames!!

Had to do some fancy replaces to get round it.

 

[catch.saravana]

I'm sure if you search the KB you can find articles on migrating from v9 or v10 to v11.

@Rob Fitzpatrick - I could see articles that explains more from db migration perspective. Do we have any document that would outline the code issues that we might be facing during migration on any document; I couldn't find any. If we don't have any I will have to compile the code base against 11.6 and resolve issues by going through the error list.

 

[Rob Fitzpatrick]

@Rob Fitzpatrick - I could see articles that explains more from db migration perspective. Do we have any document that would outline the code issues that we might be facing during migration on any document; I couldn't find any. If we don't have any I will have to compile the code base against 11.6 and resolve issues by going through the error list.

Here are a few:

What are the required steps to migrate 4GL application between major versions
Knowledge Article

A number of ActiveX/OCX/COM controls that have been working correctly under OpenEdge 10.2B and earlier releases fail under OpenEdge 11.x.
Knowledge Article

Critical Alert – Issues migrating applications that use ActiveX/COM objects to OpenEdge 11.
Progress KB - Critical Alert – Issues migrating applications that use ActiveX/COM objects to OpenEdge 11.

The ComponentOne VSFlexGrid custom properties dialog fails to open in OpenEdge 11.6.
Progress KB - The ComponentOne VSFlexGrid custom properties dialog fails to open in OpenEdge 11.6.

Unable to add Crystal ActiveX Report Viewer Control to OpenEdge 11 ABL window on Windows 7 / 2008.
Progress KB - Unable to add Crystal ActiveX Report Viewer Control to OpenEdge 11 ABL window on Windows 7 / 2008

Cannot drop Imageman 8 ActiveX control on a container in 11.x using AppBuilder.
Progress KB - Cannot drop Imageman 8 ActiveX control on a container in 11.x using AppBuilder

When migrating Progress versions, is it possible to use conmgr.properties and ubroker.properties from the previous version with the new version of Progress OpenEdge?
Knowledge Article

How to upgrade a SmartObjects application to a later version?
Knowledge Article

ADM1 application recompiled in OpenEdge 10 runs but intermittently fails with error 5635.
Knowledge Article

In addition to the above, there are two ways to look at this. One is "what needs to change or might break given a large jump in Progress version (9.x to 11.6)". The other is "what needs to change or might break given an OS upgrade and (probably) a change in server hardware". I assume that with a jump this large you aren't staying on the same OS or hardware.

Re: OpenEdge change:

• Does your application have dependencies on code in old Progress frameworks (e.g. Dynamics, Smart Objects, FastTrack) that might no longer work or be supported?
• Does your application have dependencies on code in old third-party frameworks or utilities (e.g. PDFInclude, SMTPMail, etc.)?
• Does your code use identifiers that are now reserved ABL keywords?
  
• Does your code depend on ABL bugs or runtime/compiler quirks that some programmers regarded as features (e.g. "dot comments", ignored type mismatches in IF functions, statements coming after an unconditional return, etc.)?
• Does your application use image PLs that have to be rebuilt in the new compiler? People remember to rebuild their code PLs but sometimes forget to rebuild image containers.
• Does your application use any features that are now on the published list of deprecated features? If so they should still work but you should have a plan in place to redesign those parts of your application. E.g. RECID function, EDITING block, CHOOSE statement, the SQL-89 interface, worktables, etc.
  
• Does your application use any features that are now on the published list of de-supported features? If so, they won't work at all in 11.6. E.g. DB extents on raw partitions (phased out in 10.1A), etc.
• Does your application rely on product/platform combinations that are no longer available? E.g. OpenEdge on Linux for PowerPC (phased out in 11.3), DataServer for HP-UX 32-bit (phased out in 10.1C), DataServer for ODBC (phased out in 11.6), etc.
• Do you have application clients moving from a 32-bit Progress runtime to a 64-bit OE runtime, thus breaking some 32-bit specific features or integrations?
• Does your application depend on integration with third-party solutions (e.g. Microsoft Office, web browsers, BI tools, etc.) that may also be upgrading, where changes in that third-party code (interfaces, default values, deprecated features, etc.) could break your features?
• Does your application include modified versions of Progress code that may need to be updated, e.g. web-disp.p?

Re: OS change:

• Does your code take dependencies on functions in old versions of OS shared libraries/DLLs that have been removed, deprecated, had signatures changed, been superseded by more secure variants, etc?
• Do you have any OS-specific code (use of OS-COMMAND, SYSTEM-DIALOG PRINTER-SETUP) that could break or behave differently than before on the new OS? OS-COMMAND in particular can be a treasure trove of compatibility issues and undocumented dependencies.
• Does the more stringent security configuration in the new OS cause application issues or break assumptions made by your original developers? E.g. firewall on by default, file system more tightly locked down by sysadmin, insecure services like telnet or FTP deactivated or removed, etc.
• Does your new host have a very long hostname that might upset OpenEdge?

This is by no means a comprehensive list but you get the idea. If your code isn't "pure" ABL (i.e. it directly or indirectly interacts with something outside the AVM), you should evaluate the potential for it to break when running in a newer OS.

 

[ForEachInvoiceDelete]

We had all of our progress browsers go an annoying grey colour instead of blue when using multi-select during a major upgrade.

Took me a while to turn that crap off.

My advice : - Test test test.

 

[Cringer]

It's an ini setting

 

[ForEachInvoiceDelete]

Yeah i found it in the end.

But much anger from my part at progress changing the default behavior. If i wanted crappy opaque grey selected highlights i'd have turned it on somehow.

 

[Cringer]

You aren't alone being annoyed at that one. I quite like it, in terms of a feature as you maintain colour differentiation, even on a browse with a single result. But yeah, the ability to switch it on would have been a better way.

 

[Rob Fitzpatrick]

@catch.saravana
If you're wondering how I came up with that list of articles, I just typed "upgrade 10.x to 11.x" into ProKB (available for download here) and sifted through the results. I often find ProKB to be more useful for searching the KB than the search function in the online KB.

 

[Cringer]

The KB is now also fully Google searchable, something PSC made a bit of a meal about at EMEA PUG, so: Google

 

[TomBascom]

The KB has been Googleized for a long time. I'm not sure why they thought that was worth mentioning.