Pegasus Opera 3 SQL SE - SAM Health Checker query

Good afternoon all,

Do any of you have much experience in the use of the SAM - Health Check function to health check existing Opera 3 VFP data, prior to migrating it to Opera SE?

I have a customer with 52Gb of Opera 3 VFP data, and I am looking to investigate how much effort would be involved in migrating it to Opera SE.

The SAM - Health Checker generates in excess of 700,000 errors!

That number doesn't phase me because, in my time at Pegasus, I saw many data sets that generated hundreds of thousands of errors where, as is the case with my customer a referential integrity error in one large table can, itself, generate tens, if not hundreds, of thousands of errors.

My concern is that the large number of errors appear to be generated because my customer is not using Stock Control and, by implication, is using the Product File. The majority of errors are generated because the Health Checker is looking for values, and records, that relate specifically to the use of Stock Control and, when not finding them, generates a referential integrity error (or a few hundred thousand thereof :-) ).

To my mind, this is a defect, as the Health Checker appears not to be taking the customer's Opera 3 activation into account when performing its checking.

I have conversed with Pegasus regarding this, and they don't seem to be able to grasp the issue, suggesting that it would be an enhancement to modify the Health Checker, and that I should simply "fix" the underlying data integrity issues. I have started to "fix" the data integrity issues, to fool the Health Checker into believing that Stock Control is in use, but it is a tedious, and laborious, job, and not one that I feel I should be doing, for the want of the Health Checker not generating the errors in the first place.

Has anyone else encountered a similar problem, particularly where Stock Control/Product File is concerned?

Also, what are your thoughts on the above? Am I right in insisting that this is a defect?

I don't recall the exact design of the Health Checker but:

1) If it doesn't take into account an Opera 3 system's activation, then all sorts of referential integrity issues would be generated where various modules are not activated

2) If it does take into account an Opera 3 system's activation, then surely the failure to detect between Stock Control and Product File is a defect?

I'm very much interested in hearing your thoughts, particularly if it provides me with more ammunition with which to go back to Pegasus, otherwise I'll stand corrected.

Much appreciated

Steve

Find more posts tagged with

Pegasus - Partner General Discussions

Accepted answers

All comments

michaelc

Hi Steve

Yes we have had the same issue when migrating a company which was the product file rather than the full stock control module, we spoke to Pegasus regarding the same error being reported with a blank warehouse record their respond was to ignore referential integrity errors and proceed away I did however run the command below on the itran to populate the missing warehouse which is health check is looking for.

replace all it_cwcode with "MAIN" for empty(it_cwcode)

I am not sure what has changed within Opera but on older invoicing documents the warehouse was set to MAIN automatically if the product file was in use but on newer versions Opera is leaving this field blank.

I could not get Pegasus to accept that this was an issue either, however running the command above removed thousands of issues allowing us to find other errors which did need looking at
esolving.

Hope this is of some us to you.

Michael

alan-bourke

Hi Steve

I think the crux of this is that DOLINE gets populated with a warehouse code even if SOP is not present (and CWARECSTWH are therefore empty) is that right ?

If you create a fake entry in CWARE for MAIN does that placate the checker ? Or just clear out the DOLINE warehouse field ?

alan-bourke

IMO you have a valid point in what you say about SAM not checking things that the customer isn't activated for. If it was me I would just create 'fake' records in CWARE and CSTWH on the VFP side to get it migrated and then delete them in the SQL server database.

use z_cware in 0 alias cware

use z_cstwh in 0 alias cstwh

use z_cname in 0 alias cname

Insert into cware (cw_code, cw_desc) values ("MAIN", "MAIN")

Insert into cstwh (cs_ref, cs_whar) select cn_ref as cs_ref, "MAIN" as cs_whar from cname

I had the same issue - the customer was importing sales transactions and had the Stock module but did not use it, and had not created a product file via SOP, so the cname file was empty.

Opera VFP does not check that the imported sa_product exists as 'cn_ref' in cname and neither does SE!

To get round the problem I copied the sa_product field into sa_exten for both sanal and hsanal then cleared these fields.

After I did the migration I just copied them back again and cleared sa_exten

I also have an issue with palloc and salloc IDs no longer existing in stran and ptran, which O3 VFP doesn't seem to mind.

Steve Loader

Thank you for your prompt response @MichaelC.

It is good (if you see what I mean) to hear that someone else has experienced the same issue with regards to the Product File, and that it's just not me (or, potentially, my customer's data).

Thank you for your suggestion in terms of "fixing" the data to help reduce the number of erroneous referential integrity errors.

I will keep you posted.

Kind regards

Steve

Steve Loader

Hi Alan,

Nice to hear from you :-)

Thank you for your suggestions on how to the "fix" the customer's data in order to fool the health Checker into thinking that Stock Control is in use, and thus not generate all the erroneous referential integrity errors.

I will endeavour to return to this issue tomorrow, and implement your suggestions.

I will let you know how it goes.

Kind regards

Steve

Steve Loader

Hi Carolyn,

Thank you for getting back to me.

As with @MichaelC, it is good to know that other people are experiencing the same issue.

Thank you too for your suggestions as to how to "fix" the customer data.

I will endeavour to implement these tomorrow, and let you know if they do the trick.

Yes, unfortunately, VFP is very lax in terms of database integrity, it will happily allow invalid content to be stored in a field of a given data type. Good, in that it prevents Opera crashing every 5 minutes, but not good in simple terms of data integrity. SQL Server, on the other is, rightly so, far stricter in terms of data integrity, hence the provision of the SAM - Health Checker. However, if you're going to provide such a tool, then the user needs to have every confidence that it generates the correct results.

Kind regards

Steve

Steve Loader

Thank you @MichaelC, @alan-bourke , and @ch , for your responses, and for all your suggestions with regards to "fixing" my customer's data.

I will endeavour to implement the necessary changes tomorrow, see what results I get, and let you all know.

I had already made a number of "fixes" to the customer data, based on the erroneous referential integrity errors, but either they weren't correct or, hopefully, I just had to implement a good few more.

However, one piece of good news is that I continued my discussions with the Pegasus Support Manager, and my insistence that this is a defect. It has been provisionally agreed, further development analysis notwithstanding, that this is a defect, and SCR OPERA-4806 has been raised to investigate and (hopefully) resolve the issue. Again, I will keep you all posted.

Thank you all again, and I'll contribute here when I have some further news.

Kind regards

Steve

Copyright © 2025 Infor. All rights reserved.