You can manully drop the DF_vendrOrderLine_quantity constraint on the vendrOrderLine.quantity column then run the upgrade and re-add the constraint afterwards, but this is basically what the updated migration does 🤔
I was checking for the constraint DF_vendrOrderLine_quantity and dropping it if it existed, but it looks like in a previous version it was added as DF__vendrOrderLine__quantity (note the use of double underscores) and so the error remained.
I've now updated it to drop both spellings 👍
UPDATE RC 50 is there now, or you can apply the manual fix as mentioned above
The struggle continues, unfortunately. Just reporting back what we found :)
After the re-try with the most recent package version (3.0.0-rc0049), there is still a DB error thrown:
We tried it again locally, and it passed at the clear version, but whenever we pushed it further, it stops the application from booting up. Below is the stack trace we see now:
[12:27:10 INF] Acquiring MainDom.
[12:27:10 INF] Acquired MainDom.
[12:27:11 INF] Starting 'HttpHeadersPlan'...
[12:27:11 INF] At installedHttpModule
[12:27:11 INF] Done (pending scope completion).
Unhandled exception. [12:27:11 ERR] Unhandled exception in AppDomain (terminating).
System.ApplicationException: Unable to run migrations as no upgrade engine found for the configured provider: System.Data.SqlClient
at Vendr.Persistence.Migrations.DbUpVendrMigrationsRunneSystem.ApplicationException: Unable to run migrations as no upgrade engine found for the configured provider: System.Data.SqlClient
at Vendr.Persistence.Migrations.DbUpVendrMigrationsRunner.MigrateUp()
at Vendr.Umbraco.Events.Notification.Handlers.RunVendrMigrations.Handle(UmbracoApplicationStartingNotification notification)
at Umbraco.Cms.Core.Events.NotificationHandlerWrapperImpl`1.<>c__DisplayClass0_0.<Handle>b__1(INotification theNotification)
at Umbraco.Cms.Core.Events.EventAggregator.PublishCore(IEnumerable`1 allHandlers, INotification notification)
at Umbraco.Cms.Core.Events.NotificationHandlerWrapperImpl`1.Handle(INotification notification, ServiceFactory serviceFactory, Action`2 publish)
at Umbraco.Cms.Core.Events.EventAggregator.PublishNotification(INotification notification)
at Umbraco.Cms.Core.Events.EventAggregator.PublishAsync[TNotification](TNotification notification, CancellationToken cancellationToken)
at Umbraco.Cms.Infrastructure.Runtime.CoreRuntime.StartAsync(CancellationToken cancellationToken, Boolean isRestarting)
at Umbraco.Cms.Infrastructure.Runtime.CoreRuntime.StartAsync(CancellationToken cancellationToken)
at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken)
at SImpl.Runtime.Host.SImplHost.StartAsync(CancellationToken cancellationToken)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(IHost host)
at Pride.Angel.Web.Program.Main(String[] args) in C:\azp\agent\_work\84\s\src\Pride.Angel.Web\Program.cs:line 57r.MigrateUp()
at Vendr.Umbraco.Events.Notification.Handlers.RunVendrMigrations.Handle(UmbracoApplicationStartingNotification notification)
at Umbraco.Cms.Core.Events.NotificationHandlerWrapperImpl`1.<>c__DisplayClass0_0.<Handle>b__1(INotification theNotification)
at Umbraco.Cms.Core.Events.EventAggregator.PublishCore(IEnumerable`1 allHandlers, INotification notification)
at Umbraco.Cms.Core.Events.NotificationHandlerWrapperImpl`1.Handle(INotification notification, ServiceFactory serviceFactory, Action`2 publish)
at Umbraco.Cms.Core.Events.EventAggregator.PublishNotification(INotification notification)
at Umbraco.Cms.Core.Events.EventAggregator.PublishAsync[TNotification](TNotification notification, CancellationToken cancellationToken)
at Umbraco.Cms.Infrastructure.Runtime.CoreRuntime.StartAsync(CancellationToken cancellationToken, Boolean isRestarting)
at Umbraco.Cms.Infrastructure.Runtime.CoreRuntime.StartAsync(CancellationToken cancellationToken)
at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken)
at SImpl.Runtime.Host.SImplHost.StartAsync(CancellationToken cancellationToken)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(IHost host)
Ended up with the revert now to the previous version.
Hope it helps to spot some further improvements and bullet-proofing the process of migrations up?
Is this published to azure? There is something in azure setup that defaults the DB provider to System.Data.SqlClient when neither Vendr or Umbraco support this. It needs to be Microsoft.Data.SqlClient.
You can explicitly set the provider in your connection string details in app settings by adding another entry for umbracoDbDSN_ProviderName with a value of Microsoft.Data.SqlClient
PS as mentioned in my last reply, the most recent release version is RC 50 which is where the latest fix for both spellings of the default constraint was added, so if you are trying RC 49 it won't fix it.
We ensured we have Microsoft.Data.SqlClient set for the connectionString in the config.
We deployed to Azure.
We still experience issues with starting the app (it tries to call System.Data.SqlClient though...)
Stacktrace:
[13:31:42 INF] Acquiring MainDom.
[13:31:42 INF] Acquired MainDom.
[13:31:42 INF] Starting 'HttpHeadersPlan'...
[13:31:42 INF] At installedHttpModule
[13:31:42 INF] Done (pending scope completion).
[13:31:42 WRN] No last synced Id found, this generally means this is a new server/install. A cold boot will be triggered.
Unhandled exception. [13:31:42 ERR] Unhandled exception in AppDomain (terminating).
System.ApplicationException: Unable to run migrations as no upgrade engine found for the configured provider: System.Data.SqlClient
at Vendr.Persistence.Migrations.DbUpVendrMigrationsRunneSystem.ApplicationException: Unable to run migrations as no upgrade engine found for the configured provider: System.Data.SqlClient
at Vendr.Persistence.Migrations.DbUpVendrMigrationsRunner.MigrateUp()
at Vendr.Umbraco.Events.Notification.Handlers.RunVendrMigrations.Handle(UmbracoApplicationStartingNotification notification)
at Umbraco.Cms.Core.Events.NotificationHandlerWrapperImpl`1.<>c__DisplayClass0_0.<Handle>b__1(INotification theNotification)
at Umbraco.Cms.Core.Events.EventAggregator.PublishCore(IEnumerable`1 allHandlers, INotification notification)
at Umbraco.Cms.Core.Events.NotificationHandlerWrapperImpl`1.Handle(INotification notification, ServiceFactory serviceFactory, Action`2 publish)
at Umbraco.Cms.Core.Events.EventAggregator.PublishNotification(INotification notification)
at Umbraco.Cms.Core.Events.EventAggregator.PublishAsync[TNotification](TNotification notification, CancellationToken cancellationToken)
at Umbraco.Cms.Infrastructure.Runtime.CoreRuntime.StartAsync(CancellationToken cancellationToken, Boolean isRestarting)
at Umbraco.Cms.Infrastructure.Runtime.CoreRuntime.StartAsync(CancellationToken cancellationToken)
at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken)
at SImpl.Runtime.Host.SImplHost.StartAsync(CancellationToken cancellationToken)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(IHost host)
You're right. Azure App Settings kept the connection string we deleted to fall back directly to the one from the code.
The weird fact is that the connection string seems to be "ok".
We had the "SQLAzure" selected as a type and tried later the SQL Server one. Both resulted in error. Do you know what should be done to avoid it? Maybe it's worth documenting?
Ultimately you need to ensure a umbracoDSN_ProviderName connection string setting is present and is set to Microsoft.Data.SqlClient.
As I say though, this is technically an Umbraco issue as much as a Vendr issue. Umbraco also requires Microsoft.Data.SqlClient, it's just our migrations pick this up sooner.
Updating Vendr to 3.0.0-rc breaks
Hi Vendr team,
we tried to bump our empty Vendr 2.3.4 to the recent 3.0.0-rc to be up to date, but the startup failed with the database error as below:
Is it something what should be addressed in the migration/update logic or there is anything that we can do to make it work and pass?
Thanks in advance for your help.
Cheers, Marcin
Lol, I just fixed this 2 minutes ago 😂 https://github.com/vendrhub/vendr/issues/385
There should be a new RC 49 on the pre-release feed now.
Rocket speed! Thanks Matt. Passing it over to the team and hopefully we'll enjoy the latest and greatest ver now :)
Hi there,
we've tried to upgrade to the recent RC 49, but still have the same error :(
Is anything else that can be done to bypass it?
Cheers, Marcin
Same exact error? That's strange.
You can manully drop the
DF_vendrOrderLine_quantityconstraint on thevendrOrderLine.quantitycolumn then run the upgrade and re-add the constraint afterwards, but this is basically what the updated migration does 🤔Ok, looks like I found the culprit.
I was checking for the constraint
DF_vendrOrderLine_quantityand dropping it if it existed, but it looks like in a previous version it was added asDF__vendrOrderLine__quantity(note the use of double underscores) and so the error remained.I've now updated it to drop both spellings 👍
UPDATE RC 50 is there now, or you can apply the manual fix as mentioned above
The struggle continues, unfortunately. Just reporting back what we found :)
After the re-try with the most recent package version (3.0.0-rc0049), there is still a DB error thrown:
We tried it again locally, and it passed at the clear version, but whenever we pushed it further, it stops the application from booting up. Below is the stack trace we see now:
Ended up with the revert now to the previous version.
Hope it helps to spot some further improvements and bullet-proofing the process of migrations up?
Is this published to azure? There is something in azure setup that defaults the DB provider to
System.Data.SqlClientwhen neither Vendr or Umbraco support this. It needs to beMicrosoft.Data.SqlClient.You can explicitly set the provider in your connection string details in app settings by adding another entry for
umbracoDbDSN_ProviderNamewith a value ofMicrosoft.Data.SqlClientSee Umbraco's documentation here specifically on provider names https://our.umbraco.com/documentation/Reference/Configuration/ConnectionStringsSettings/
PS as mentioned in my last reply, the most recent release version is RC 50 which is where the latest fix for both spellings of the default constraint was added, so if you are trying RC 49 it won't fix it.
Quick update from the field:
Stacktrace:
Any ideas?
What does azure say your app settings are?
Hello again!
You're right. Azure App Settings kept the connection string we deleted to fall back directly to the one from the code.
The weird fact is that the connection string seems to be "ok".
We had the "SQLAzure" selected as a type and tried later the SQL Server one. Both resulted in error. Do you know what should be done to avoid it? Maybe it's worth documenting?
Ultimately you need to ensure a
umbracoDSN_ProviderNameconnection string setting is present and is set toMicrosoft.Data.SqlClient.As I say though, this is technically an Umbraco issue as much as a Vendr issue. Umbraco also requires
Microsoft.Data.SqlClient, it's just our migrations pick this up sooner.is working on a reply...