IMigrator.GenerateScript() creates invalid Access SQL for the __EFMigrationsHistory table check

When creating a migration sql script for a context with migrations, the scripts contains an invalid statement:

IF NOT EXISTS (SELECT * FROM `INFORMATION_SCHEMA.TABLES` WHERE `TABLE_NAME` = '__EFMigrationsHistory') THEN CREATE TABLE `__EFMigrationsHistory` (
        `MigrationId` varchar(150) NOT NULL,
        `ProductVersion` varchar(32) NOT NULL,
        CONSTRAINT `PK___EFMigrationsHistory` PRIMARY KEY (`MigrationId`)
    );
;

This results in “Invalid SQL statement; expected ‘DELETE’, ‘INSERT’, ‘PROCEDURE’, ‘SELECT’, or ‘UPDATE’.” ACCESS SQL doesn’t support the IF statement.

            await context.Database.EnsureDeletedAsync();
            await context.Database.EnsureCreatedAsync();
            var pendingMigrations = (await context.Database.GetPendingMigrationsAsync()).ToList();
            
            var migrator = context.Database.GetService<IMigrator>();
            string last = null;
            string current = null;
            try
            {
                //await context.Database.EnsureCreatedAsync();
                foreach (var migration in pendingMigrations)
                {
                    current = migration;
                    var upSql = migrator.GenerateScript(last, current,
                        idempotent: false);
                    using (var transaction = await context.Database.BeginTransactionAsync())

                    {
                        await context.Database.ExecuteSqlRawAsync(upSql);
                    }
                }
            }
            catch (Exception e)
            {
                throw new AggregateException($"Up Migration {current} failed.", e);
            }

Applying the Migration directly with MigrateAsync() works correctly.

Issue114.zip

[MichaelSteinecke]

That works! Thank you 😃

[lauxjpn]

Is it possible to use the EntityFrameworkCore.Jet.Data based procedural statements when creating migrations or execute SQL?

@MichaelSteinecke As long as you run the statements through our EntityFrameworkCore.Jet.Data ADO.NET provider (which is implicitly being used by EntityFrameworkCore.Jet), and as long as those statements are correctly formatted so that the provider recognizes them, this should work fine, since it is exactly what our internal query generator and migration script generator does.

For example, most procedural statement support was added to EntityFrameworkCore.Jet.Data because it was necessary to make migrations work.

---

For example I need to create a view which may or may not exists before.

This should work.

The general IF (...) THEN ... statement syntax can be seen here:

https://github.com/bubibubi/EntityFrameworkCore.Jet/blob/7de5da5755e1146f1cf51e260227bea3da8d7784/src/EFCore.Jet.Data/JetCommand.cs#L28

The general INFORMATION_SCHEMA support can be seen here:

https://github.com/bubibubi/EntityFrameworkCore.Jet/blob/7de5da5755e1146f1cf51e260227bea3da8d7784/src/EFCore.Jet.Data/JetStoreSchemaDefinition/JetInformationSchema.cs#L14-L16

https://github.com/bubibubi/EntityFrameworkCore.Jet/blob/7de5da5755e1146f1cf51e260227bea3da8d7784/src/EFCore.Jet.Data/JetStoreSchemaDefinition/JetInformationSchema.cs#L24-L33

You would check for views in a similar way as for tables, by using INFORMATION_SCHEMA.TABLES. The default SchemaProvider that is being used to retrieve this information is PreciseSchema, which will just forward the GetTables() call to AdoxSchema:

https://github.com/bubibubi/EntityFrameworkCore.Jet/blob/7de5da5755e1146f1cf51e260227bea3da8d7784/src/EFCore.Jet.Data/PreciseSchema.cs#L20-L21

AdoxSchema.GetTables() will then return both, tables and views:

https://github.com/bubibubi/EntityFrameworkCore.Jet/blob/7de5da5755e1146f1cf51e260227bea3da8d7784/src/EFCore.Jet.Data/AdoxSchema.cs#L78-L157

The format of the returned table can be seen here:

https://github.com/bubibubi/EntityFrameworkCore.Jet/blob/7de5da5755e1146f1cf51e260227bea3da8d7784/src/EFCore.Jet.Data/JetStoreSchemaDefinition/SchemaTables.cs#L7-L21