In preparation for OI10 I would like to again address converting my reports to OIPI.net. I have 659 stored procedures that use OIPI. A lot of those routines are incompatible with OIPI.net with a change in fonts etc.

What is the best way to gently convert to OIPI.net. Should I change all "Set_Printer" to "Set_Printer1", then set SYSENV*CFG_OIPI to VSPRINTER2. Is that a viable option although quite a large task.

How many developers have changed their application to OIPI.net?

Any advice would be grateful.

Chris

I can confirm that changing Set_Printer to Set_Printer1, then change SYSENV*CFG_OIPI to VSPRINTER2 does NOT retain the old OIPI but still uses OIPI.net.

This does not behave the same if changing Set_Printer to Set_Printer2 to use the OIPI.net while having VSPRINTER.

Not sure where to go from here.

Chris.

Hi, Chris. If you desire the majority of your "legacy" usage to be OIPI "classic", then I suggest you set your CFG_OIPI record to use OIPI classic. This is done by setting field 1 to VSPRINTER. Note that the CFG_OIPI record that's used might be an application or user specific one, so you need to look in SYSENV for the following records:

CFG_OIPI*<appid>*<username>

CFG_OIPI**<username>

CFG_OIPI*<appid>

in addition to the "general purpose" CFG_OIPI record. For example, if you only want this behavior for the application MYAPP, then you should update/create the SYSENV record CFG_OIPI*MYAPP so that field 1 says VSPRINTER.

Also note that the vsprinter value is cached, so you must exit and re-enter OI after changing the CFG_OIPI record.

Setting the cfg record to this will mean that all your legacy code will use the OIPI "classic" that it was designed for, and you won't need to edit hundreds of routines. Moving forwards, you can explicitly use SET_PRINTER2/GET_PRINTER2 in your new code to explore/test its functionality and usefulness for you, without impacting the existing reports.

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

Hi Chris

It is possible to write a program that:

- selects some programs in SYSPROCS (perhaps based on a prefix) that would identify your 659 stored procedures;

- reads the source code of each program in a loop;

- makes changes to the source code (eg swap "Set_Printer" to "Set_Printer1"

- writes the changes back;

- compiles the new source code.

Check out the Repository function.

I can post some code if you're interested.

Cheers

Robert Lee

Thanks Robert,

But I tried it on one routine by changing Set_Printer to Set_Printer1 and change CFG_OIPI to VSPRINTER2 did not get the desired result. The OIPI printout still used the .Net version NOT the classic OIPI. Not like using Set_Printer2 and having VSPRINTER, then get the .net printout.

Will continue using the classic OIPI and see if all the issues have been resolved in OI10.1. If not then I will continue using the old OIPI and use OIPI.net on exceptional circumstances like putting an image from OI into an excel spread sheet.

I would be interested in how many developers are using OIPI.net

Chris

Hi Chris

We're using classic OIPI. We found it quicker than OIPI.NET but apart from that we kept getting intermittent error messages popping up that needed to be OK'ed for the report to complete.

There's a thread on our issues here:

The biggest downside we have noticed of OIPI Classic is the .PDF's produced can't be copied and pasted.

Robert

Thanks Robert,

I will continue with clasic OIPI and see if the OI10.1 OIPI.net has solved the OI9.4.6 issues.

Will report back once OI10.1 is available.

Chris

View this thread on the Works forum...