Comparison Issues w/ Logging (Storage) Enabled

I'm running Schema Compare for Oracle 5.2.4.1424

There are comparison issues for script or snapshot sources if the logging storage option is enabled in SCO, but the logging attribute is not captured in the respective script or source.

Scenario:
- logging attribute on source (script or snapshot) is empty (not captured)
- logging storage option is enabled in SCO comparison
- the SCO comparison identifies all instances of NULL value for logging in the source as a difference w/ the target -- applies to tables, indexes, and lobs (if lob storage option is enabled)
-- this doesn't make much sense since a NULL logging value is not an option (i.e. a NULL indicates use the default for tablespace)
-- if there is no LOGGING value specified in the source it would seem appropriate to exclude the logging value from the comparison for that object (and perhaps issue a Warning -- Low or Medium)
-- for tables w/ an identified logging difference no UPDATE SQL is generated
-- for indexes and LOBS the generated SQL is incomplete / invalid:  
   -- examples (the following statements are incomplete and fail when executed)
      --- ALTER INDEX activity_type_pk ; 
      --- ALTER TABLE survey_task MODIFY LOB (sys_nc00012$);

Tagged:

Best Answer

  • Alex BAlex B Posts: 1,153 Diamond 4
    Answer ✓
    Hi @mbruegel,

    Righto, I believe I see what you are seeing.  I created a table and deployed the changes to a scripts folder first including all storage options.  Then I edited the script to remove the LOGGING keyword from the index and table. 

    Now when I compare only including the "logging" storage option I see this, which is it highlighting the textual differences:

    which is your third point I believe.  This is highlighting the textual differences from the lines that exist in both, by removing these from the target it's telling it to the use tablespace default as you say and so if we are synchronizing the target to be the same, we want it to use the tablespace default in that case.  I'm not sure why a warning would be appropriate here as this doesn't affect the data in the table or impact performance (that I am aware of) and if you are telling it to synchronize from something that doesn't have the LOGGGING keyword then you should understand that this is going to remove that keyword from the target.

    Now I do see that it's not generating the deployment script correctly - there is no mention of the table and there is only an ALTER INDEX <index name> ; with no content (no LOB in my example), which is a problem and I've raised this as OC-1079 and will update here when I have more information on it!

    Kind regards,
    Alex
    Product Support Engineer | Redgate Software

    Have you visited our Help Center?

Answers

  • Alex BAlex B Posts: 1,153 Diamond 4
    Hi @mbruegel,

    Sorry for the delay in getting back to you on this, and I wish it was with better news.

    The team have reviewed the issue along with other priorities and have decided not to fix the issue I'm afraid.

    Do let me know if you have any questions regarding this.

    Kind regards,

    Alex

    Product Support Engineer | Redgate Software

    Have you visited our Help Center?
Sign In or Register to comment.