Activity overview
Latest activity by Phil_Factor
Each feature branch will need its own migration files starting with a baseline file that represents the database at the point of branching. You can use the same instance for each feature as long as there is no overlap. This means they cannot alter each other's tables and so on. It's not ideal, but we've all worked that way in the past. Come back and ask if I haven't made myself clear! / comments
Each feature branch will need its own migration files starting with a baseline file that represents the database at the point of branching. You can use the same instance for each feature as long as...
I'd be grateful for a solution to this as well. / comments
I'd be grateful for a solution to this as well.
May I suggest that this is added? It shouldn't be too hard to do, seeing that you just need a CLI utility that the user can then schedule. The code to do the reporting is already in the GUI / comments
May I suggest that this is added? It shouldn't be too hard to do, seeing that you just need a CLI utility that the user can then schedule. The code to do the reporting is already in the GUI
Im starting a project to use a number of different database systems with a single database code in Flyway, using placeholders to iron out some of the differences. For this, spawn could be very valuable. I’m making two database, one real and the other an enhancement of the old pubs database. I’m eyeing up spawn for the standard test-runs. The motivation for the development is to try to make a database portable enough to be able to move it to the cheapest possible hosting without being boxed in to a single RDBMS. / comments
Im starting a project to use a number of different database systems with a single database code in Flyway, using placeholders to iron out some of the differences. For this, spawn could be very valu...
Done. That link wasn't that easy to find! / comments
Done. That link wasn't that easy to find!
Yes, you can do it with SQL. It is possible to script out just the extended properties using SSMS, or by using PowerShell/SMO. These can then be executed for every database in your list. If every database has the documented objects it should work easily. It is, I think, also possible to get SQL Compare to generate a script. for just syncing the Extended properties. In both cases, you need to ensure that only the MS_Description properties get copied! / comments
Yes, you can do it with SQL. It is possible to script out just the extended properties using SSMS, or by using PowerShell/SMO. These can then be executed for every database in your list. If every d...
It is an excellent way of using SQL Doc. I give several examples of how to do this in PowerShell here on the site. See: https://www.red-gate.com/hub/product-learning/sql-doc / comments
It is an excellent way of using SQL Doc. I give several examples of how to do this in PowerShell here on the site. See: https://www.red-gate.com/hub/product-learning/sql-doc
[image] (Nervously looking through some of my own articles and blogs) / comments
(Nervously looking through some of my own articles and blogs)
I think we're all agreed that 'string_alias' = <expression> has been deprecated, but that <column_alias> = <expression> is still supported, though it is not in the SQL standard, nor currently recommended by Microsoft.
Most of these checks are merely advisory, and SQL Prompt evidently allows you to switch on and off all the Code checks individually. It is always down to individual judgement and preferences. After all, some people still like using the old Sybase inner join syntax which is still likewise supported by SQL Server and free from deprecation (unlike the sybase outer join syntax!) . I agree that the description should be elaborated to point out that <column_alias> = <expression> is still supported.
Was either 'string_alias' = <expression> or <column_alias> = <expression> ever in the SQL Standard? I've looked back to 1999 but can't find it. / comments
I think we're all agreed that 'string_alias' = <expression> has been deprecated, but that <column_alias> = <expression> is still supported, though it is not in the SQL standard, nor currently rec...
I'm afraid that, despite pining for the 'good old' assignment syntax, I count this as a 'SQL Smell'. SQL Syntax uses the AS keyword to specify an alias. Microsoft recommend the AS syntax. Nowhere does the current MS documentation suggest using the old Sybase dialect that uses the assignment = operator. This is retained by SQL Server for the time being purely for backward compatibility. As Joe Celko says 'The ANSI Standard is <expr> AS <alias>; this is used in many other places, too. Your dialect (Sybase Dialect) overloads the equal sign, destroys portability and it is difficult to read if you know SQL.'
One detail in the description ought to be clarified. It is only the 'string_alias' = <expression> syntax that is deprecated. For now the <column_alias> = <expression> is still there but is liable to be deprecated in future releases because it is non-standard. The SQL standards and Microsoft both say we should use the AS syntax. / comments
I'm afraid that, despite pining for the 'good old' assignment syntax, I count this as a 'SQL Smell'. SQL Syntax uses the AS keyword to specify an alias. Microsoft recommend the AS syntax. Nowhere ...