Comments
Sort by recent activity
Parses for me if I do this in the server. Is this manually written code committed in git as a file? We use specific formats for code as we generate this for text storage. I might be wrong, but I don't think we support manually editing/adding sql files. [image] / comments
Parses for me if I do this in the server. Is this manually written code committed in git as a file?We use specific formats for code as we generate this for text storage. I might be wrong, but I don...
Window is reserved as of SQL 2022. It was marked at some point in the past as this was added to ANSI SQL. This isn't a word that should be used as an identifer. That being said, it's valid in SQL 2017, and we shouldn't throw an error on it, in SC or Prompt. Prompt appears to work, and if I connect SQL Source Control to SQ L2017 (14.0.3465) with SOC v 7.6.34.18144 and this code works: CREATE TABLE window (myid INT);
I'd like to know what code you are having an issue with, what version of source control to reproduce this. If you can't post code here, you can email to support@red-gate.com and ref this post URL. / comments
Window is reserved as of SQL 2022. It was marked at some point in the past as this was added to ANSI SQL. This isn't a word that should be used as an identifer.That being said, it's valid in SQL 20...
What version of SQL Server? Window is a reserved word: https://learn.microsoft.com/en-us/sql/t-sql/language-elements/reserved-keywords-transact-sql?view=sql-server-ver16 You can't use that as an identifier / comments
What version of SQL Server? Window is a reserved word: https://learn.microsoft.com/en-us/sql/t-sql/language-elements/reserved-keywords-transact-sql?view=sql-server-ver16You can't use that as an ide...
There isn't a great solution, and we don't really automate this. I'd do what you listed above, but I'd also think about repeating this. You ought to have a script that fixes these views after a restore. In SQL Clone or RG Clone, we'd link a script to the creation of the test database image, but as a general rule, your process should be scripted as follows:
backup ProdA
backup ProdB (these can be in parallel)
restore TestB (from ProdA backup)
restore TestB (from ProdB backup)
run CREATE OR ALTER VIEW on TestB to fix all references
run CREATE OR ALTER VIEW on TestA to fix all references.
If you have the views (or other code) in version control, you can search/replace the code and then run that. You could use SQL Compare once you've done this once to save a project that looks at your specific views (or all views) and then writes to a scripts folder. You could then compare this folder on disk to the restored db, but if you added/changed views, this wouldn't work. My long term suggestion is to move to synonyms for each object and have all code reference these. Then when you restore, you still need steps 5/6 above, but you are only changing synonyms, which is less maintenance as multiple views/procs/etc could reference one synonym. / comments
There isn't a great solution, and we don't really automate this.I'd do what you listed above, but I'd also think about repeating this. You ought to have a script that fixes these views after a rest...
- Image pathing is slightly broken, but I think some of this will work once we get the domain live, the /xxx will work. Right now it's /sql-saturday-website/xxx, which is hard to account for. - List of events comes from a static file. I think this repo is private, but the test page I have is here: https://github.com/way0utwest/jekylltest/blob/main/_data/otherevents.yml - Curated, by a committee. I think that a group of volunteers would be good for handling PRs here that allow someone to add to this list. Or build tools to create a yml file with the events / comments
- Image pathing is slightly broken, but I think some of this will work once we get the domain live, the /xxx will work. Right now it's /sql-saturday-website/xxx, which is hard to account for.- List...
FYI: https://voiceofthedba.com/2021/03/15/rebuilding-sql-saturday-picking-a-board-of-directors/ / comments
FYI: https://voiceofthedba.com/2021/03/15/rebuilding-sql-saturday-picking-a-board-of-directors/
To add to what Kendra notes, we typically create the artifact, by looking at the target and project and finding the differences. If you can't see the client dbs, this becomes more complex, but you can do this with PoSh and our cmdlets. Just note that if the client has changed anything in the db, your migration scripts, might have issues. / comments
To add to what Kendra notes, we typically create the artifact, by looking at the target and project and finding the differences. If you can't see the client dbs, this becomes more complex, but you ...
I agree with what Kendra has listed here. This isn't a simple thing to do, and not necessarily something you do all at once. There is risk here that can break things. I'd actually like #2, and work through a table(s) and it's relationships in stages, then repeat. For example, I might 1. Add an int key to the parent table and populate it in a deployment 2. add an int PK/FK to a dependent table. 3. Populate a child new PK with the new values from the parent, using the old PKs to join tables I'd repeat that for one table. Then start to slowly move through other tables. If I'm sure a single table is done, I'd also start refactoring the app to use the new key. As with complex changes in a database, I might stagger this across time, slowly working on the refactoring to ensure my app continues to work while disruptions and risk are minimized. / comments
I agree with what Kendra has listed here. This isn't a simple thing to do, and not necessarily something you do all at once. There is risk here that can break things. I'd actually like #2, and work...
It's not duplicate work, to me. This is a shift left of much of the script review from post VCS in a release, to a point in time where you load the SCA project from your changes in SSC (SQL Source Control, not SQLServerCentral). Once you have changes, you can load them into a migration script. This is checked into git twice, but git doesn't case. This also lets you then track what items are loaded. I wouldn't load every change as a migration script, but only once I thought we were close to being done and needed customization. If you don't need customization, there is a need to generate and commit one script, but I'd think that's minor compared to the shift left capability of script review early on. / comments
It's not duplicate work, to me. This is a shift left of much of the script review from post VCS in a release, to a point in time where you load the SCA project from your changes in SSC (SQL Source ...
Can you post the code? / comments
Can you post the code?