Comments
Sort by recent activity
Hi Alex, My main points about the type change are as follows: 1. dropping the associated collection type could be a high(er)-risk activity -- as it is an implicit result of an object change not an explicit one made to the collection type -- i.e. even if the object is re-created I may be in danger of losing any grants on the object, if I do not include grants in my comparison actions 2. the implicit drop / recreate of the associated collection object appears unnecessary -- why not use the FORCE option? (Note: it does persist once used -- but have you identified a use case where that is undesirable?) -- or at least check if the object DDL and *if* it contains the FORCE keyword don't drop the owning collection object to begin with Also note have an open support case that exhibits a similar behavior: (63 exit code is set when a tablespace for a table is changed) / comments
Hi Alex,My main points about the type change are as follows:1. dropping the associated collection type could be a high(er)-risk activity -- as it is an implicit result of an object change not an ex...
With version 5.2.5 the Warning: High message appears to be suppressed -- however it is still identified in the exit code status on the command line (correctly so -- because of a drop statement) . Run the sco.exe command line (deployment is not necessary) - w/ the /abortonwarnings:high switch you get an exit code 63 - w/o the switch you get the exit code: 61 This appears to be a bad / incomplete fix. - I see that FORCE argument has been added to the create or replace of the type (it wasn't there in 5.2.4 -- see generated SQL above) - The drop of the associated collection type is still there although it doesn't need to be (because of the FORCE option added to the CREATE OR REPLACE TYPE) - the returned exit code (63) is technically correct, because of the drop statement (the WARNING HIGH has been removed -- suspect because of the addition of the FORCE, but the associated DROP is still there -- so this is incomplete and inconsistent) Here is the update SQL generated by SCO which clearly still has the DROP statement (-- and therefore should be a High warning). - fix would appear to be: remove the associated collection drop (unnecessary because of the use of FORCE) - you may need to do some investigation for the appropriate DDL sequence if the object or collection type is referenced by a persisted column -- FORCE can't be used under that scenario -- -- Script generated by Schema Compare for Oracle 5.2.5.1424 on 30/04/2019 15:47:06 -- SET DEFINE OFF DROP TYPE parameter_var_t; CREATE OR REPLACE TYPE PARAMETER_PAIR_OBJ_T FORCE AS OBJECT (param_name VARCHAR2(50), param_value VARCHAR2(500)); / CREATE OR REPLACE TYPE PARAMETER_VAR_T AS VARRAY(10) OF parameter_pair_obj_t; / / comments
With version 5.2.5 the Warning: High message appears to be suppressed -- however it is still identified in the exit code status on the command line (correctly so -- because of a drop statement) ....
In the 5.6.2 product version(s) I've found that the \!. works to exclude all objects. The tricky thing is multiple excludes for named objects (need to use the and \& vs a comma): e.g. the following syntax appears to work: \!<object1 name pattern>\&\!<object2 name pattern>\&\!<objectN name pattern> Where as this doesn't: \!<object1 name pattern>, \!<object2 name pattern>, \!<objectN name pattern> Documentation needs to be updated with appropriate syntax and examples. / comments
In the 5.6.2 product version(s) I've found that the \!. works to exclude all objects.The tricky thing is multiple excludes for named objects (need to use the and \& vs a comma):e.g. the following s...
I'm also having issues w/ the new ignore filter in Source Control for Oracle v. 5.2.4.1926 Specifying multiple object names in the ignore pre-filter rule doesn't appear to work properly: For a positive include I've tried the following combinations: "+OBJECT_1_NAME$","+OBJECT_2_NAME$" "^OBJECT_1_NAME$","^OBJECT_2_NAME$" OBJECT_1_NAME,OBJECT_2_NAME For a negative exclude I've tried: \!OBJECT_1_NAME, \!OBJECT_2_NAME \!OBJECT_1_NAME, \&\!OBJECT_2_NAME Nothing appears to produce the desired result. In each case the filter appears to catch only a single object. Help would be much appreciated. I also note that in one of the screenshots in the documentation, there appears to be the use of brackets [] in the filter. I've tried using both brackets [] and parentheses () as a grouping mechanism, but bot produce errors (invalid syntax). / comments
I'm also having issues w/ the new ignore filter in Source Control for Oracle v. 5.2.4.1926Specifying multiple object names in the ignore pre-filter rule doesn't appear to work properly:For a positi...
Yeah the /abortwarnings is too blunt as columns or tables may be legitimately dropped as part of a deployment. That said there should be some safeguards against nuking your entire schema! (if you really want to fine, but it should be explicit -- like a purge target option) I also note that the source script folder doesn't even need to exist -- specify FOO as the schema name (where that folder doesn't even exist) and the target gets purged as well! Sanity check could be -- the standard sub-folders under the schema (at least check for one of them) -- otherwise an empty source it is in effect a purge all objects operation. / comments
Yeah the /abortwarnings is too blunt as columns or tables may be legitimately dropped as part of a deployment.That said there should be some safeguards against nuking your entire schema! (if you r...
As noted we deploy our schemas by the schema owner -- using RedGate combined w/ source control (Source Control for Oracle) that should give us nice per schema versioned representations of the individual schemas. -- If using the super user approach, we'd have a multi-schema model to manage / untangle which could get complicated / messy rather quickly (e.g. too many developer DBAs in the kitchen). -- Right now that appears to be the only way to manage multi-schema deployments with a single scripted deployment. (I have not tried that approach so I'm not sure how well the inter-dependency is managed.) What would be really nice is: 1. a way to specify inter-dependencies between distinct schema models (i.e. source scripts) so that they could be deployed in a coordinated way. 2. a way to specify logon info for multiple schema owners (so the owner deploys DDL to their own schema) While not an every day occurrence, the scenario that requires a multi-schema deployment w/ coordinated steps between each does come up. / comments
As noted we deploy our schemas by the schema owner -- using RedGate combined w/ source control (Source Control for Oracle) that should give us nice per schema versioned representations of the indiv...
Here is a link for the privs required by Schema Compare for Oracle: https://documentation.red-gate.com/sco5/requirements/permissions-required-to-use-schema-compare-for-oracle In our shop we manage deployment by schema owner -- the owner has the necessary grants to deploy into their own schema only. If you want to have a super user that can deploy to any schema see the above for the list of necessary create any privs. - martin / comments
Here is a link for the privs required by Schema Compare for Oracle:https://documentation.red-gate.com/sco5/requirements/permissions-required-to-use-schema-compare-for-oracleIn our shop we manage de...
Some SQL IDE's have the ability produce a data model diagrams of limited utility. For MS SQL I think SQL Server Management Studio has something built-in. On the Oracle side SQLNavigator, Toad, or PL/SQL Developer have limited capabilities. To really create and manage data models used as the starting point for development (or to reverse engineer a complex schema/database) turn to a full-feature data modeling tool like Idera's (Embarcadero) ER/Studio, or ERWin. / comments
Some SQL IDE's have the ability produce a data model diagrams of limited utility.For MS SQL I think SQL Server Management Studio has something built-in.On the Oracle side SQLNavigator, Toad, or PL/...
Issue is resolved in release 5.2.5.1424 / comments
Issue is resolved in release 5.2.5.1424
Associated bug ID: OC-1037 / comments
Associated bug ID: OC-1037