Activity overview
Latest activity by unclebiguns
FIgured this out. It was the CopyTo. removed the CopyTo and the log backups went back to under 2 minutes. / comments
FIgured this out. It was the CopyTo. removed the CopyTo and the log backups went back to under 2 minutes.
Log Backups Taking 2-3hrs to complete and should take minutes
I have a case where my log backups using SQLBackup are taking 2-3hrs to complete and they should take less than minute according the data in backupset.In backupset the largest difference between ba...
Welcome Rosanna. Great to have you aboard. / comments
Welcome Rosanna. Great to have you aboard.
Sheldon,
One selling point for me would be the fact that a homegrown solution likely isn't documented well/documentation isn't updated so when the creator of the solution moves on, much of the knowledge on how to use it goes with them. With a purchased product you have support, documentation, and a user community. / comments
Sheldon,
One selling point for me would be the fact that a homegrown solution likely isn't documented well/documentation isn't updated so when the creator of the solution moves on, much of the know...
A couple of comments about the new Code Analysis.
Seems to work pretty well, but when there is code analysis message, it keeps the normal SQLPrompt Intellisense pop-ups from working. So if you use a stored procedure and violate the named parameter use rule you can't get the definition of the stored procedure.
The "Schema name for table or view is not specified" rule should not apply to temp tables. It looks like this is only an issue if you add an index to a temp table the index definition violates the rule. Like this:
CREATE TABLE #test(colA CHAR(1) NOT NULL, colB CHAR(1) NOT NULL);
CREATE NONCLUSTERED INDEX IX_test ON #test (colA);
SELECT T.colA, T.colB FROM #test AS T
/ comments
A couple of comments about the new Code Analysis.
Seems to work pretty well, but when there is code analysis message, it keeps the normal SQLPrompt Intellisense pop-ups from working. So if you use...
Just installed it. Will let you know what I think. / comments
Just installed it. Will let you know what I think.
way0utwest wrote: »
Thanks, Jack, but a couple questions.
Why is the issue tough with SSDT? Because you need a comparison to get changes from the live dev db to the model ? Is is the offline model that's cumbersome?
Also, why do you need SSDT projects with SQL Source Control? Are the SQL Source Control projects not enough or are you trying to maintain history?
Steve, sorry for the delayed response. Busy over the holiday.
Yes, the comparison between live DB and the project model is a step I'd prefer not to have to do. With creating an SSDT project from a legacy database, I have always seen errors that keep the project from successful building because of past development practices (not removing unused objects, etc...) that the effort to cleanup the project so it will be build is very time-consuming and painful.
So what is missing from SQL Source Control are database level settings/configs, like collation, recovery model, ANSI settings, Isolation level. Database projects include all these settings and since collation, isolation level, and ANSI settings can affect how code works and performs, I see them as things that need to be under source control. I'm sure I could add them to a SQL Source Control project, but I get that by default with SSDT. I also like the "build" functionality in SSDT which, to my knowledge, SQL Source Control doesn't do. With SQL Source Control, I LOVE the integration into SSMS and the direct link to an active database. I just want both. / comments
way0utwest wrote: »
Thanks, Jack, but a couple questions.
Why is the issue tough with SSDT? Because you need a comparison to get changes from the live dev db to the model ? Is is the offline mo...
I haven't implemented automated deployments for databases/data anywhere yet, but most people I have been involved with as an employee and a consultant are in the 1 and 2 categories and a few years from 3 and 4.
The offline SSDT model is pretty good for greenfield development but can be painful for getting legacy databases into source control and for ongoing development where you are fixing bugs and testing in a dev environment and then, at least the way I work, adding the code to the SSDT project. I would love an more integrated model where I have the database project in SSDT, but have a plug-in to SSMS/SOS/VS that allows me to connect an active database to the project. Essentially make SQL Source Control work with SSDT projects in a supported manner. / comments
I haven't implemented automated deployments for databases/data anywhere yet, but most people I have been involved with as an employee and a consultant are in the 1 and 2 categories and a few years ...
Ben,
Glad my post helped some. I agree with David that you should go the Git model as that is what almost all development shops are using now and TFS has a Git mode that most TFS shops are moving to.
I would recommend playing with the combination of SQL Source Control and Database Projects. It isn't perfect, but it can work. Here's the latest documentation on using the 2 together. I have played with it on the side, but haven't used it as my process yet. / comments
Ben,
Glad my post helped some. I agree with David that you should go the Git model as that is what almost all development shops are using now and TFS has a Git mode that most TFS shops are moving ...
Ben,
The only thing I don't think is pretty normal for working with SSDT Database Projects is the not putting in Source Control right away. I do work in a disconnected model similar to how you describe. My process currently using SSDT is to:
Create Database Project and develop initial objects in SSDT
Publish to a development (usually local) SQL Server
Make changes & unit test on the development server
Push changes to Database Project from Dev server
Publish from Database Project to QA
Promotion of code is always from the database project, so no new changes should be made anywhere but development.
It isn't ideal and I do like the integration of SQL Source Control into SSMS. You can use both SSDT database projects and SQL Source Control, but there are some things that aren't supported when you do both.
The reason I use Database Projects in SSDT instead of SQL Source Control is because in a database project the database settings are also part of the project and under source control, while SQL Source Control only includes the schema and things like SET options and collation definitely affect the way you have to code.
-Jack / comments
Ben,
The only thing I don't think is pretty normal for working with SSDT Database Projects is the not putting in Source Control right away. I do work in a disconnected model similar to how you des...