Output generated with connection is different from one using --no-connection

@BigYellowHammer reported this in the Gitter chat:

Hey guys, im using FM for SQLServer and I noticed that output generated with proper connection string is slightly different from the one generated using --no-connection With connection:

BEGIN TRANSACTION
/* CreateTable FluentLog */
CREATE TABLE [dbo].[FluentLog] ([Id] BIGINT NOT NULL IDENTITY(1,1), [Text] NVARCHAR(255) NOT NULL, [Text2] NVARCHAR(255) NOT NULL, CONSTRAINT [PK_FluentLog] PRIMARY KEY ([Id]))
/* -> 1 Insert operations completed in 00:00:00.0069825 taking an average of 00:00:00.0069825 */
INSERT INTO [dbo].[VersionInfo] ([Version], [AppliedOn], [Description]) VALUES (201905202105, '2019-07-10T13:14:32', N'AddLogTable')
/* Committing Transaction */
COMMIT TRANSACTION

Without connection:

CREATE TABLE [dbo].[FluentLog] ([Id] BIGINT NOT NULL IDENTITY(1,1), [Text] NVARCHAR(255) NOT NULL, [Text2] NVARCHAR(255) NOT NULL, CONSTRAINT [PK_FluentLog] PRIMARY KEY ([Id]))
GO
/* -> 1 Insert operations completed in 00:00:00.0069621 taking an average of 00:00:00.0069621 */
INSERT INTO [dbo].[VersionInfo] ([Version], [AppliedOn], [Description]) VALUES (201905202105, '2019-07-09T08:25:56', N'AddLogTable')
GO

I would really like to have those BEGIN/END TRANSACTION statements outputted in --no-connection mode. I analyzed the code and looks like MigrationScopeHandler is behaving differently and as a result - different statements gets added to output. Do you have any ideas/hints what I can do to modify this behavior?

[progmars]

I, too, vote for this issue.

We are using dotnet-fm tool during our automated build process to generate SQL scripts for DBAs to review, and it would be handy to be able to add automatic transactions around the script.

Of course, it would be even better if there was a way to generate more "fool-proof"full SQL migration script that does the following:

• adds the check for existence of VersionInfo table and creates one if it doesn’t exist (the same way as it happens when running with connection)

• (this might need a totally new feature) - wraps every migration fragment with a check for existence of corresponding VersionInfo.Version value and skips the ones that are found. But, to play it safe, the skipping should be allowed only while no migration has been executed yet to prevent from applying migrations out of order.

  OR

• a command line parameter to specify the starting version number for the output script.

This way, the DB admin could safely run entire script without having to manually trim away the starting portion to skip old migrations (and having to check the VersionInfo.Version table to see where to start trimming).

[jzabroski]

Sorry, one thing I missed:

--preview mode is supported by the FluentMigrator.DotNet.Cli package’s command line parameters

So, there is three execution toggles:

1. Preview, with or without transaction
   • Governed by --preview-only
2. Transaction, with or without connection
   • Governed by TransactionBehavior enum on MigrationAttribute as well as at the global level.
3. With or without connection
   • Governed by --no-connection

I don’t think you should fix all of this, but you’re welcome to try. If you do, do it in smaller PRs so it’s easier to review and more mentally rewarding for you to see progress.