I have several inherited accounts. CMG account No bitmap warnings, DEALER account many bitmap warnings.

Inheritance chain as follows:

SYSPROG/FRAMEWORKS/PBC/CMG No errors

SYSPROG/FRAMEWORKS/PBC/DEALER Many bitmap warnings

The repository entries in OI9.4.6 look identical

Migration warnings as follows:

Warning for "DEALER*OIWINIV_BOM" [Error reading SYSREPOS image entity DEALER*IMAGE*BMP*BUT-033 for imageCount update [FS100 - Record "DEALER*IMAGE*BMP*BUT-033" does not exist.]] Warning for "DEALER*OIWINIV_BOM" [Error reading SYSREPOS image entity DEALER*IMAGE*BMP*BUT-033 for Button update [FS100 - Record "DEALER*IMAGE*BMP*BUT-033" does not exist.]]

Warning for "DEALER*OIWINIV_BOM" [Error reading SYSREPOS image entity DEALER*IMAGE*BMP*BUT-050 for imageCount update [FS100 - Record "DEALER*IMAGE*BMP*BUT-050" does not exist.]] Warning for "DEALER*OIWINIV_BOM" [Error reading SYSREPOS image entity DEALER*IMAGE*BMP*BUT-050 for Button update [FS100 - Record "DEALER*IMAGE*BMP*BUT-050" does not exist.]]

Etc.

Should I be concerned?

Chris

Hi Chris,

When you look those images in your v9 DEALER app - are actually they valid? Can you go to the v9 System Editor and open the "DEALER*IMAGE*BMP*BUT-050" record in the SYSREPOS table?

If you run the SCAN_REP tool on your v9 DEALER app - do you see any errors relating to these images?

Carl Pates

Hi Carl,

I can open the "DEALER" app, goto the repository/General/Windows Components/Images/Bitmaps then double click on BUT-050 and display the bitmap via Paint.

So I assume all the connections are correct.

Hope this helps.

Chris.

Hi Chris,

But can you open the record in the System Editor and does SCAN_REP give you any warnings? Are these images inherited? from the parent app?

Carl Pates

Hi Carl,

I can open the record SYSREPOS/PBC*IMAGE*BMP*BUT-050 but SYSREPOS/DEALER*IMAGE*BMP*BUT-050 does not exist.

The DEALER account is inhertited from the PBC account.

The inheritence chain is as follows:

SYSPROG/FRAMEWORKS/PBC/DEALER

I will check the scanrep but should I also rebuild the reportsitory indexes?

Chris

Hi Chris,

Rebuilding won't hurt - but before you do any major surgery on the repository make sure you have a backup just in case.

Carl Pates

When you say "have a backup" do you mean of the REPOSITORY file(s)? or the entire OI program folder?

I've got a VERY OLD (from Arev DOS 2) to try out in OI 10.1 and am concerned about how I can best review the results of a SCAN_REP. I've never messed with repository entries directly.

Are the types of errors reported of concern? Are they any that one can just delete?

Dave Harmacek - Harmacek Database Systems - near Boston, MA USA

Hi Dave

I always take a backup of everything, or at least everything in REVBOOT. Storage is cheap, so why take the chance on missing something?

Depends on the error - mostly the problems you find are orphaned entities

e.g.

Things that have a SYSREPOS record that points to to an image file that doesn't exist, or a SYSREPOS record for a form that doesn't exist in SYSREPOSWINS etc. Stuff like that - usually they can be deleted if the entity shouldn't be there.

The other common thing is events where the form has been deleted but an event got left, so those sorts of things can be deleted, unless you wanted the form and you can recreate/copy it from a backup somewhere else.

If you get an error and you're not sure just post it here and we can talk about it more.

Regards

Carl Pates

Thanks Carl.

In these days of OI supporting a website it means that the Production system is 24/7.

So, I suppose I will kill the OengineServer, do a backup, and then a Scan_Rep.

Dave Harmacek - Harmacek Database Systems - near Boston, MA USA

Finally got back to this task. First, I did the Rebuild System Index, Sync Database, and Sync Stored Procedures.

Then, I ran SCAN_REP and included the "Use strict validation criteria for Entity IDs".

Looking at the Reason list I see "Bad App". All the App ID with this was something I don't remember so I deleted all of those.

There were 4 Reason left:

<b>No Body</b> I'm concerned especially with those in App ID SYSPROG. Do I dare delete them? What about those of the target App ID?

<b>Orphan and Orphan?</b> What are they and how are they different?

<b>Orphan</b> I suspect these can be deleted, even in my target App ID? Again, what about if in SYSPROG?

Dave Harmacek - Harmacek Database Systems - near Boston, MA USA

<b>Orphan?</b> There are some in my target App ID. But, there are many in SYSPROG. Concerned?

Thanks, Dave

Hi Dave,

No-Body

This is when there's a SYSREPOS record for an entity but no "source" record

e.g. MYAPP*STPROC**MYPROC in SYSREPOS but no MYPROC*MYAPP record in SYSPROCS and so on.

Unless you can supply the missing source record (if it really should be there) these should be deleted.

Orphan and Orphan?

These are basically event source or exes (Not Promoted!) that are not linked to a form (via the Uses/Used By list) or have no corresponding form/control . In Pseudo code it looks something like this:

   if FormHasSysReposRecord Then

      If EventIsInFormSubList Then 

         RepairSubSuperIfNeeded - All OK.

      End Else

         // Event is not linked - should it be?

         If IsEventForAControl Then

            If FormRecordExists Then

               If ControlExistsOnForm Then

                  // We have the event - we have the control

                  // form is NOT to linked to it (missing in SUB 

                  // entities)

                  ORPHAN?

               End Else

                  ORPHAN

               End

            End Else

               ORPHAN

            End

         End Else

            // We have the form - we have the event but the 

            // form is NOT to linked to it (missing in SUB 

            // entities)

            ORPHAN?

         End

      End

   End Else

      ORPHAN

   End

Basically - ORPHAN means that it's an event without any "parent", ORPHAN? means all the bits are there but there's no link between them. The former should probably be deleted , the latter? That's up to you :)

Regards

Carl Pates

View this thread on the Works forum...