Activity overview
Latest activity by LittleColin
This is also a requirement for us. We use DBAmp to synchronize tables from Salesforce, we leave it up to DBAmp to manage the columns on these tables and the data but we would like to use RedGate to patch in additional indexes. / comments
This is also a requirement for us. We use DBAmp to synchronize tables from Salesforce, we leave it up to DBAmp to manage the columns on these tables and the data but we would like to use RedGate to...
Why so much unnecessary SQL for unchanged tables?
Not a big issue but I was wondering if it's posible to supress dropping/creating constraints for tables that have not changed.
We currently review the SQL scripts before they get released and it ma...
Splitting the steps does introduce issues because the dependencies are not managed for me. Our current full process is:
1. Synchronise basic static data (only managed in development)
2. Add any missing row data (/include:Missing)
3. Add any column updates where the columns are not managed in production (using /ignoreColumns)
However if data is added in step 1 that is dependent on the missing rows added in step 2 then it fails. If I move step 1 to after step 2 then I have the same dependency issue but the other way around. Ideally I need to be able to run all of the above in a single go and let RedGate figure out the dependencies.
Is it likely that this can be done via the API? / comments
Splitting the steps does introduce issues because the dependencies are not managed for me. Our current full process is:
1. Synchronise basic static data (only managed in development)
2. Add any mis...
Ah I think the documentation is incorrect. http://www.red-gate.com/supportcenter/C ... 700076.htm
This shows that ReseedIdentity is not a default option but it does appear to be. By specifying the options explicitly (and not specifying ReseedIdentity) I get the result I want. / comments
Ah I think the documentation is incorrect.http://www.red-gate.com/supportcenter/C ... 700076.htm
This shows that ReseedIdentity is not a default option but it does appear to be. By specifying the o...
Should /include:missing reseed?
I'm trying to only INSERT data that exists in the source table but doesn't exist in the destination so I used the /include:Missing which seems to almost do what I want (via the command line).
It co...
Forgot to mention, we are using the command line to achieve this at the moment.
I think I've solved this by doing a two step script generation.
1. Use /include:Missing to add any additional rows introduced in Dev and carry across all columns.
2. Use /include:Differences /ignoreColumns:MyProductionMasterColumn to carry across updates without affecting columns that are edited in production. / comments
Forgot to mention, we are using the command line to achieve this at the moment.
I think I've solved this by doing a two step script generation.
1. Use /include:Missing to add any additional rows in...
IgnoreColumns only for existing rows?
Is it possible to ignore a certain column but only where a data row already exists?
For example, we create scripts during development with some basic data that can be customised in production. We d...
Fantastic, I can confirm it fixes my issue. Thanks for the fast turnaround. [image] / comments
Fantastic, I can confirm it fixes my issue. Thanks for the fast turnaround.
Incorrectly UPDATING excluded tables
Using SQLDataCompare command-line, I am specifically including a subset of tables however I am getting UPDATE statements for tables not in my list.
The tables are explicitly wrapped in \[Tablename\...
The last step should work because the preceding data migration step would have populated the columns with data. This can be guaranteed because the source data has already got the NOT NULL constraint so must have values for the additional column.
(note that I haven't yet tried the SQL Data Compare to see if it can add data for the added columns but am assuming it can - as opposed to only working on a row added or removed basis - or am I wrong about that?)
But thanks for your reply - am looking forward to this feature being added. / comments
The last step should work because the preceding data migration step would have populated the columns with data. This can be guaranteed because the source data has already got the NOT NULL constrain...