User profile for way0utwest

Thanks, I'll ask about this. I've got 3.0.18 as well. The generation should be very quick / comments

Thanks, I'll ask about this. I've got 3.0.18 as well. The generation should be very quick

0 votes

I'm slightly confused, but maybe you can help. When you say modestly sized, I assume you have a number of tables, views, procs, etc. When you say the import and Generate Scripts take a long time to complete, I assume you mean that only one object changed, so why was this taking so long? If that's right, the reason is that we need to build a dependency tree. You change one proc, but does that cause other issues in a chain? When we generate a script, we need to determine not only what changed, but what the potential issues are. If you're changing one procedure, that's usually all that's affected but we can't know that, especially if the change is from another client SSMS/VSCode/ADS. So we walk a tree to see what's changed and then need to compare that to the existing view to capture the change. At times generating the script is non-trivial, and it can be hard to do this accurately without doing a full compare. / comments

I'm slightly confused, but maybe you can help. When you say modestly sized, I assume you have a number of tables, views, procs, etc. When you say the import and Generate Scripts take a long time to...

0 votes

Can I ask what changes you're making here? Specifically? Adding a column ought not to do this, but if you are doing other things, this might be an issue. There's no magic to gettting close to zero downtime. We are bound by the rules of SQLServer, and what we want to do with RG tools is make it easy to do what you'd do manually. Recommending a temp table is sometimes good, sometimes bad,but I'd have to know more here about what to do. However, you need to understand the way that your system works and what method for making changes is apporpriate. I do think that some of the more complex changes are better handled with pre/post scripts, and I'm glad these got added for this reason. I also like the SQL Change Automation client in VS, as this gives me complete control and replays the changes in the same way for downstream environments. This lets me control the way we make changes, as I might tackle different column adds in different ways, depending on the table. You won't get zero downtime. You can get very close, and a table rename is often the quickest way. You can front this with a view as well, and recompiling the view to point to a new table is often even quicker, but there are always some locks being held. Here I'd actually do this if I needed the temp table for the Sales table. 1. Make dbo.Sales2 as the new table, with new schema 2. Copy data from dbo.Sales to dbo.Sales2 (this could be one step 3. Rename dbo.Sales to dbo.Sales_Old 4. Rename dbo.Sales2 to dbo.Sales 5. cleanup any data added between step 2 and 3. If you try to make this one transaction, you won't get zero downtime. If you are trying to add a column and populate all rows with data in the same step, you won't get zero downtime. Actually, you don't get downtime, but blocking. If you provide more information, we can help determine how to attack this problem. / comments

Can I ask what changes you're making here? Specifically? Adding a column ought not to do this, but if you are doing other things, this might be an issue.There's no magic to gettting close to zero d...

0 votes

Apologies, the target is really a release term. That's where you pick the end database. For build, you need a temporary place to compile the code. The temporary server is where the code would run. This needs to support TRIM() [image] / comments

Apologies, the target is really a release term. That's where you pick the end database. For build, you need a temporary place to compile the code. The temporary server is where the code would run....

0 votes

What's the build target? The only compiler the build process has is the SQL Server engine. If you've targeted LocalDB or a version that doesn't support TRIM(), then things might not work. / comments

What's the build target? The only compiler the build process has is the SQL Server engine. If you've targeted LocalDB or a version that doesn't support TRIM(), then things might not work.

0 votes

The developers are aware this is an issue and they're looking into it. No word on when this might be fixed, but I'm hoping soon. / comments

The developers are aware this is an issue and they're looking into it. No word on when this might be fixed, but I'm hoping soon.

0 votes

Is there broken code after the area you're trying to format? If I get my code into a batch, it seems to format. If you have an example of the code for me to test, I'd be happy to. I have 9.2.7 on this machine, but 9.2.9 on another. / comments

Is there broken code after the area you're trying to format? If I get my code into a batch, it seems to format. If you have an example of the code for me to test, I'd be happy to. I have 9.2.7 on t...

0 votes

I've noticed this as well. I've sent a note off to see if this is a fundamental behavior change or a bug. I have been able to get this to work by putting a "GO" before my statement/query and then formatting it. / comments

I've noticed this as well. I've sent a note off to see if this is a fundamental behavior change or a bug. I have been able to get this to work by putting a "GO" before my statement/query and then f...

0 votes

Sorry, this process sometimes is a bit of a chicken and egg, going around in circles when trying to explain the process. In case someone else is following, here's what I recommend. Let's say I have a procedure that I wanted created called dbo.SetDateforClass. This looks like this in my programmable object: CREATE OR ALTER dbo.SetDateforClass   @ClassID int , @dt date as  begin update Class  set StartDate = @DTs where ClassId = @ClassID end I add this to my database and then add a migration script that looks like this.  exec dbo.SetDateforClass 1, getdate() exec dbo.SetDateforClass 2, getdate() Now, when I refresh the project, this compares to the shadow database. The migration scripts execute first, then the programmable objects. In this case, I'll get an error as the proc doesn't exist in Shadow yet, so the script fails. This worked in the main development database since the chronology was correct in how I built the objects. To fix this, I recommend this: change the migration script to:  if not exists( select name from sys.objects where name = 'SetDateforClass')   begin CREATE OR ALTER dbo.SetDateforClass   @ClassID int , @dt date as  begin update Class  set StartDate = @DTs where ClassId = @ClassID end goexec dbo.SetDateforClass 1, getdate() exec dbo.SetDateforClass 2, getdate() This will deploy the procedure as part of the migration script and then execute it. Later, the programmable object will overwrite this procedure with the same definition and the compare with the Shadow db for validity, as well as a build or downstream deploy, will work. If the procedure gets updated with a new parameter or different logic, that will be deployed, but this migration won't run again. However, if a new developer sets up from scratch, when they load the project and pick databases, this migration script will work (likely no data, so no effect) and then the updated procedure definition will be deployed as a part of the programmable object deployment. / comments

Sorry, this process sometimes is a bit of a chicken and egg, going around in circles when trying to explain the process. In case someone else is following, here's what I recommend.Let's say I have ...

0 votes

I'm assuming your migration script uses the procedure to do some work? I'd that right? What is say here is you can really only do one thing and thats include the proc crrate in the migration script . It will also be in the programmable object and that should just ovewrite with the version stored there. I'd do this in an idempotent way so that in future deployments if the proc exists, we don't try to recreate it .Not create it alter but an if exists(check sysobjects). Toss isn't great but it does solve the issue here. In the future, this also ensures builds work from scratch . Even if the proc changes, the valid version of the proc that works with this migration script works. I think if you deoy the proc first, to both shadow sha downstream environments, then add the script this may work, but if have to test. However, any deployments to a new system, like a new developer setup, would fail so I'd rather just inline the proc in the migration script, knowing that all future changes are handled as a part of the programmable object / comments

I'm assuming your migration script uses the procedure to do some work? I'd that right?What is say here is you can really only do one thing and thats include the proc crrate in the migration script ...

0 votes

How can we help you today?

way0utwest

Comments