Comments
Sort by recent activity
See the command line documentation: https://documentation.red-gate.com/sco5/using-the-command-line/command-line-switches#Commandlineswitches-/source:%3Cvalue%3E You're current problem is that you're specifying the server's physical IP address which isn't in you TNSNames.ora file (i.e. it thinks the IP is a TNS names entry). Docs for the direct connection (using host's IP) appear to indicate that you need to specify the service name (DB instance name) after the server host name or IP and before the schema name(s) in the braces {}. (user/pass|/)@host[:port]/service{SchemaA, SchemaB} Alternately if you have an entry (DB instance name) that is in your TNSNames.ora file use that instead of the host IP address with your current syntax and that should work just fine: (user/pass|/)@tns{SchemaA, SchemaB} / comments
See the command line documentation:https://documentation.red-gate.com/sco5/using-the-command-line/command-line-switches#Commandlineswitches-/source:%3Cvalue%3EYou're current problem is that you're ...
See the command line documentation: https://documentation.red-gate.com/sco5/using-the-command-line/command-line-switches#Commandlineswitches-/source:%3Cvalue%3E You're current problem is that you're specifying the server's physical IP address which isn't in you TNSNames.ora file (i.e. it thinks the IP is a TNS names entry). Docs for the direct connection (using host's IP) appear to indicate that you need to specify the service name (DB instance name) after the server host name or IP and before the schema name(s) in the braces {}. (user/pass|/)@host[:port]/service{SchemaA, SchemaB} Alternately if you have an entry (DB instance name) that is in your TNSNames.ora file use that instead of the host IP address with your current syntax and that should work just fine: (user/pass|/)@tns{SchemaA, SchemaB} / comments
See the command line documentation:https://documentation.red-gate.com/sco5/using-the-command-line/command-line-switches#Commandlineswitches-/source:%3Cvalue%3EYou're current problem is that you're ...
Some things to try w/o any guarantee for success: 1) try setting the Behavior option to Use forward Slash 2) try setting the Behavior option to Exclude Schema Names 3) are you executing the drop statement from within the schema that owns the object or are you running as a user w/ a DROP any PRIV?) 4) check your encoding settings: Tools / Application Options -- default is UTF-16 (I haven't had issues w/ that). Oracle SQL developer is a JAVA implementation so UTF16 would likely be most appropriate -- but you can try switching to ASCII (Sorry I use a different SQL IDE, but a SQL script is a SQL script and should behave similarly whether code generated or written from scratch -- check for any subtle syntax differences) / comments
Some things to try w/o any guarantee for success:1) try setting the Behavior option to Use forward Slash 2) try setting the Behavior option to Exclude Schema Names 3) are you executing the drop sta...
Hi Alex, I tested w/ version 5.3.1 and the abortonwarnings behavior appears to be resolved. / comments
Hi Alex, I tested w/ version 5.3.1 and the abortonwarnings behavior appears to be resolved.
The FORCE appears to persist once the object has been modified w/ a FORCE command. That, however, doesn't impact the behavior of the abort on warnings. Even more so, if SCO isn't using FORCE then it follows a drop and re-create pattern for dependent collections.
Since an object is being dropped, the ABORT on WARNINGS should probably be HIGH-- and the commadline exit code identifies it as such, but it doesn't abort before the drop as expected. Version: Schema Compare for Oracle version:5.2.5.1424: activated Command line: "C:\Program Files\Red Gate\Schema Compare for Oracle 5"\sco /source:mbruegel_parameter_Pair2.onp{MBRUEGEL} /target:mbruegel/<PWD>@<DB_INSTANCE>{MBRUEGEL} /excludedependencies /exclude:additional /loglevel:verbose /report:ObjectDiff.html /reporttype:Simple /scriptfile:SCOUpdate.sql /verbose /abortonwarnings:high Echo w/ /abortonwarnings:high echo %errorlevel% 63 Echo w/o /abortonwarnings echo %errorlevel% 61
Source: is Snapshot or Scripts folder (no difference in behavior)
Target Oracle DB: 11.2.0.4.0 / comments
The FORCE appears to persist once the object has been modified w/ a FORCE command.That, however, doesn't impact the behavior of the abort on warnings.Even more so, if SCO isn't using FORCE then it ...
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...