OpenEdge 10.2b – Invalid version Error 2888

We service different versions of OpenEdge for a software project. The entire build has been automated through Jenkins, Ant and PCT to produce artefacts for different OpenEdge version targets. So far, so good. Let’s not comment on the fact that OpenEdge 10.2b’s lifespan has ended, and focus on the more interesting part of the post.

I was recently asked to analyze a somewhat odd issue that has cropped up in the last few weeks. The application ran as expected, however one r-code caused the error “Invalid version, 1005 (excepted 1006) in object file myApplication.myClass (2888)” on runtime. Quite odd, to say the least.

According to the Progress Knowledge Base we somehow managed to produce r-code for OpenEdge 10.0a. Impossible – we always compile every file in a strictly regulated environment during our pipelines runs and I have never even seen a release pre 10.2b on our build slaves. There was just no way for this message to be accurate. Or was there a way…?

Suspecting that PCT perhaps contained old r-code which would cause us trouble during the compilation process, I set the PCT-SRC property to true to force JIT compilation of the required tool procedures. No success.

The solution came in form of the xref directives within the PCTCompile task. Setting the xmlXref property to false fixed the issue. This makes sense, considering the functionality is only available starting with OpenEdge 11.

It is, however, sort of spooky that there were no compilation problems and most of the r-code worked flawlessly… except that one, cursed class.

Relocating databases in Progress OpenEdge

One way to do it, if procopy is not an option, would be like this:

  • Copy the database and all it’s files (d*, b*, st) to the new location
  • Edit the .st file in a text-editor, replace the old path occurences with the new one
  • Open a ProEnv prompt and navigate to the database’s directory
  • Run: proutil <database name> -C truncate bi
  • Run: prostrct repair <database name>
  • Check whether all went well: prostrct list <database name>
  • If your admin server already knows the database, try to start it: dbman -db <database name> -start

A thing I noticed is the difference in output between dbman and the old Progress Explorer Tool. While the Explorer gives you some meaningful output, dbman often responds with DBMan022 which the Progress Knowledge Base refers to as a database error… duh.