I am developing an application on a stand-alone machine with XP and OI 4.1.3. OIPI32/4.1 runs beautifully, most of the time. Putting in a simple FOR…NEXT for 1000 or 2000 passes after "START32" and "STOP32" seems to get OIPI32 to run all the time.

Then, I go and deploy the four OIPI reports on a small network with a 2000 server and XP workstations and it goes to pieces. Sometimes they run, sometimes they do not, sometimes they flash open but close prematurely. No error messages. OINSIGHT.INI has the auto start and stop set to yes and you can see oipi32 running in Task Manager. The "INIT" function returns either 1 (sometimes a report runs, sometimes it does not) or -5 (report never runs). Sometimes adding "START32" or "STOP32" helps, sometimes not. Adding the FOR…NEXT does not help. If a report runs, then it runs only once and I have to restart the application. Reinstalling or copying over the developer version of OI32 does not help.

Second problem. I use the printer setup and printer buttons for all the reports. They work on all the reports except one. Copying over the PARAMS from the working reports to the non-working one does not fix that problem. In other words, that one report displays but does not print. Nothing obviously different in the code.

If I put "STOP32" anywhere after "TERM", the OIPI closes without my seeing the report. Therefore, I usually do not use "STOP32" but this should not matter since OINSIGHT.INI has the auto stop=yes".

I am calling these reports from a form and have not tried to see if they work in system monitor.

HELP!!!

Desparate in Schaumburg

Bob,

If I recall correctly, in ver 4.13 the START_32 and STOP_32 is redundant, indeed would possibly cause problems (see DOCs on this version to confirm).

Simply put, when the system boots it auto, runs the equivalent of START_32, and when the system closes down it SHOULD run the equivalent of STOP_32 (subject to the ini settings.

I would gess that there are other issues you have to deal with such as ensuring each workstation has the OCX's registered.

Richard Bright

Bob,

It sounds like you are trying to issue a START32/STOP32 everytime you run a report. Is that correct? The intent is to only run one START32 when the application loads and only one STOP32 when the application closes. Your reports should only be running INIT/TERM commands for each time you print. As Richard pointed out, OI 4.1.3 does the START32/STOP32 for you by default. Earlier versions of OI required programmer intervention.

Having said that, we have discovered some rare situations where running some versions of S/List and then running custom OIPI reports caused problems. OIPI gets foobar'd and we have to resort to drastic measures. Therefore we wrote a program called INIT_OIPI() that does the following:

1. Attempt to INIT the OIPI normally.

2. If that fails, then STOP32/START32 and then INIT again.

3. If that fails, kill the OIPI32 process using the same API commands that End Task does from the Task Manager. INIT again.

Virtually everytime the OIPI will now load, even during situations where the OIPI would normally choke.

Your second problem might be related to the problems we had with S/List. We discovered that some OIPI commands create problems for the next INIT statement. This is what caused the conflict between S/List and our custom OIPI reports (BTW, Sprezz seems to have resolved this.) At this moment I forgot what those commands are. If you post your code I might be able to spot the offending command line.

[email protected]

SRP Computer Solutions, Inc.

Don and Richard, thanks for the help. It led to the solution. I was using start's and stop's and removing them ultimated solved the problem. The real puzzle was that as I working this out, I could run a report and then all of a sudden, no more reports would run. Fiddling with the start's and stop's did not help. Then I rebooted the computer and removed all the start's and stop's and everything was fine. I guess when you missue these commands, you foul up the machine.

Richard / Don

1. Registering OCXs

Interested in your comment about registering the OCXs.

As per my earlier comments about the auto-breeding of OINSIGHT.INI files, it just isn't feasible to go round registering everything everywhere on lots of workstations, Citrix servers, etc.

I haven't done any manual registering of anything here or at client sites and haven't had any problems (until yesterday an OIPI error re non-registered SSUTIL.OCX - hopefully just a freak).

2. The "Sandra Bug"

I think we've hit a problem related to your discussion.

Two clients have each reported OIPI -4 errors in INIT ("invalid param" - which is just not true) happening at random but normally on one specific workstation at each site. User of each workstation is called Sandra. However that might just be coincidence.

One client on OI 3.7.5 and the other on OI 4.1.3

Anyone got any ideas? Could this be one to STOP32 and then START32?

Don - can you tell me how the API End Task is done from OI?

Thanks, folks!

Richard,

Interested in your comment about registering the OCXs.

AFAIK, the only other OCX's that need to be registered are VSPRINT7.OCX and VSPDF.OCX. We only register these as needed but with our OLE controls we have code that auto-registers them during the start up of the application using commands like this:

OCXCtrl=VSPRINT7.OCX"

rv=Utility("RUNWIN", "REGSVR32 /S ":OCXCtrl)

Two clients have each reported OIPI -4 errors in INIT ("invalid param" - which is just not true) happening at random but normally on one specific workstation at each site…One client on OI 3.7.5 and the other on OI 4.1.3…Anyone got any ideas? Could this be one to STOP32 and then START32?

What version of the OIPI is the OI 3.7.5 using? We never had a problem with the 16-bit version of the OIPI. Nevertheless, if your users are getting incidental INIT errors then you will have to ask them to be more observant regarding what they were doing just before running the offending report. This is what ultimately led us to figure out that S/List reports were somehow a part of the equation.

Don - can you tell me how the API End Task is done from OI?

In fairness to our client who paid for the work and to ourselves for the effort going into it we need to request that you contact us directly.

[email protected]

SRP Computer Solutions, Inc.

Don

Many thanks

1) It's easy when one knows how (or has one's brain switched on). With new network workstations, random Citrix servers, etc. this suggests some sort of control. It seems unnecessary to run this sort of stuff every time. Not to run it invites trouble. Suggests one should keep an installation log based on @STATION to know which terminals have had this registration process run.

2) They're both using 32 bit OIPI. We too found 16-bit OIPI very free from glitches and mysteries. However, when all is well 32 bit OIPI does have advantages (and is obligatory in 4.1.3).

Should one really ask two respectable ladies called Sandra what they get up to in their offices? Apart from using S/List, what other mischief could cause OIPI INIT problems?

If there is an INIT failure, what is then the way to prevent recurrence - log out of OI and in again, restart Windows, reboot PC, …?

3) Fair enough. We'll try just STOP32 & START32 if INIT fails and then crash out if a second INIT fails. If this still gives significant problems, I may indeed contact you.

Richard,

It seems unnecessary to run this sort of stuff every time. Not to run it invites trouble. Suggests one should keep an installation log based on @STATION to know which terminals have had this registration process run.

I oversimplified what we do. We actually store information in the OINSIGHT.INI file (*gasp*) so we can track whether this has already been done. However, if the application moves then this needs to be done again. We could, I suppose, track the location of REVBOOT and check that each time the application loads. However, for the moment we simply have a menu option in our Utilities menu that allows the user to run this registration logic at will.

Apart from using S/List, what other mischief could cause OIPI INIT problems?…If there is an INIT failure, what is then the way to prevent recurrence - log out of OI and in again, restart Windows, reboot PC, …?

We have been able to replicate this problem by adding a DUPLEX or PAPERBIN command in our reports. These caused INIT errors for the subsequent report. However, FWIW, when we re-run this failed report again the problem goes away on its own. We believe that the subsequent TERM command clears the deck, so to speak, so the report can run normally.

[email protected]

SRP Computer Solutions, Inc.

Don

Thanks again!

I was contemplating keeping a record in an OI file keyed on @STATION with various useful things with this flag as one of them. I suppose there are lots of ways and I can see pros and cons.

We don't use DUPLEX or PAPERBIN, so I suppose there are other (maybe many) possible culprits for this apparently random error. When the error occurs I suppose in addition to START/STOP32 we could also throw in the odd TERM for good measure!

View this thread on the forum...