Source control does not get triggers?

Ok after loading 6.4.208 I see that the DB Query (Objects + Typed Synonyms) script has reverted back. I'm not sure if it'll get triggers at this time since my pro features disappeared I cannot run SCS right now.

Your previous settings have been saved. Please open Options dialog, click Import/Export, the locate SqlAssist.sas file in 6.3 sub folder and import it.

	SysOp wrote:
	Your previous settings have been saved. Please open Options dialog, click Import/Export, the locate SqlAssist.sas file in 6.3 sub folder and import it.

Well your changelog mentions changes to DDL. I'm not sure if I want to revert my 6.3 changes back...

Though I cannot test any of the SCS items now.. no pro features are enabled.

Sorry, let me get a different license key for you that will enable the pro features

	Mindflux wrote:
	Well your changelog mentions changes to DDL. I'm not sure if I want to revert my 6.3 changes back...

You don't have to import everything. You can import the DB Query (Objects + Typed Synonyms) separately.

gemisigo wrote:

	Mindflux wrote:
	Well your changelog mentions changes to DDL. I'm not sure if I want to revert my 6.3 changes back...

You don't have to import everything. You can import the DB Query (Objects + Typed Synonyms) separately.

I know. I'm saying I don't want to (just yet).. as it seems if they changed the DDL Logic I'd like to see what changed first.. but my SCS is disabled.

It seems next to nothing changed though.. I imported my old object after copying the new one to (Copy)

	Mindflux wrote:
	Personally, I'd like to see everything that needs a collation (default or otherwise) to explicitly declare it in the DDL. That way, if your default collation changes (for whatever reason) it doesn't mess with the table data.

That's not about personal preference. There's no such setting as database default in the columns system table, that collation is explicitly set so there's no way to tell it's db default or not other than comparing it to database default. If you store that in your create scripts you'll have extremely hard time if you want to port the changes in the repository to another database with different default collation as their collation won't be database default. It'll absolutely screw everything. I had to create a database generation script two weeks ago because of the very same situation caused by messing with collation that way. It was very complex and created >70k lines of code (save-drop-recreate scripts, taking into account object dependencies) to repair the damage. I wouldn't want to have to do that again. Defaults, if they were defined that way, should stay as they are. They're defaults for a reason.

I'd like to clarify that the referenced change in DDL generation is not related to program settings. So reloading previous settings would do nothing in that sense. But if you reload old settings for all categories,, you would loose new formatting rules aided recently for MERGE and for WITH.

	SysOp wrote:
	I'd like to clarify that the referenced change in DDL generation is not related to program settings. So reloading previous settings would do nothing in that sense. But if you reload old settings for all categories,, you would loose new formatting rules aided recently for MERGE and for WITH.

But the above screenshot where I changed Objects+Typed Synonyms is what enabled me to get the triggers via SCS. Did that change as well?

As far as I know we didn't change any SQL Server related DB Queries in the options. If you wish, you can continue using the one you customized. The DB Queries are exposed for a variety of reasons, one of them is to allow users to customize queries as they see them fit. This enables users do adopt options to difference database versions and editions. I recall helping someone to change the queries to support VistaDB. The only theoretical downside to customizing the queries, is that if we introduce a new feature dependent on the updated queries and you continue using your old custom code, you may miss out on that new feature.

Alright! After resetting my repository things are looking pretty sharp in the DDL now.

One thing I do see is that the non PK/non clustered constraints kind of get tossed inbetween the table permissions.

I have:

	Code:
	GRANT GRANT GRANT GRANT ALTER TABLE ALTER TABLE GO <-- this is the ONLY go in the whole DDL, somehow it ended up here and not at the end? GRANT GRANT GRANT

From my point of view that looks correct. There could be more than 1 go in case of indexes, full text catalog, triggers, grants, etc...
By the way, the actual code is generated by the SMO (SQL Server Management Objects) which we call in the process of DDL generation for the source control.

	SysOp wrote:
	From my point of view that looks correct. There could be more than 1 go in case of indexes, full text catalog, triggers, grants, etc... By the way, the actual code is generated by the SMO (SQL Server Management Objects) which we call in the process of DDL generation for the source control.

Well it may not matter. I was just pointing it out. On one of my larger tables (with many columns) there's still just the one go at the bottom in between some alter table/grants...

No Go's in the triggers etc... but that would make sense since I don't have a GO at the end of my trigger code.