Closed KristofKlein closed 2 months ago
Hi @KristofKlein - not sure I understand the question? something with a dishwash? No, kidding. You made it work you said - using a manual step - what was this? I remember looking into this a long long time ago - but would need to get my memory awakened...:-)
So,
let me try again without a dishwasher this time (fun fact: according to my wife I don't know how to pack it - No matter what I try - it is always wrong :D so if you can help me with this as well, would be awesome :P )
All the trouble started with this flow:
In order to make it work it went like this :
So questions is the failing point 5 - how to get the Invoke-NAVApplicationDatabaseConversion run without me doing it manually in a "unhealty" container?
How do you create the container in step 4? The generic image will actually run the Invoke-NAVApplicationDatabaseConversion if you create the container with a -bakFile - but I assume that you are connecting to a SQL Server on the host or like. Obviously, the container cannot just run the Invoke-NAVApplicationDatabaseConversion on any database connection when creating the service tier - it needs to be on demand. You could try to add this to your New-BcContainer in step 4:
-myScripts @( @{ "SetupDatabase.ps1" = ". 'c:\run\SetupDatabase.ps1'; Write-Host 'Converting database'; Invoke-NavApplicationDatabaseConversion...; Write-Host 'Conversion done'" })
this will override the SetupDatabase script - call the default (which connects to the DB) and then perform the database conversion.
Yes, as I want to keep the DB on the onPrem way more powerful SQL Enterprise Server I just connect it. no bak file. So it is as I was thinking in the beginning, bak makes the Invoke, straight connect not. I mean that is fair enough. I will give the script overwrite a spin ( more or less what I was after ). If this works my life get's easier :D and that gives me more time to think about the optimal dishwasher packing :P perfect.
@KristofKlein - did it work?
I will - very soon - do the magic once more for BC v24 ( we tend to skip CU00 ;) I'll update once on the run again :)
Nope. that did not work, as the order of commands is not working, with adding the normal script in front of the "convert".
at <ScriptBlock>, C:\run\SetupDatabase.ps1: line 152
at <ScriptBlock>, C:\Run\my\SetupDatabase.ps1: line 2
so I tried to turn things around, and ended up with the issue, that I don't have the dbcredentials at hand when I need to the SQL server (would need something like this -myScripts @( @{ "SetupDatabase.ps1" = "Write-Host 'Converting database'; Invoke-NAVApplicationDatabaseConversion -DatabaseServer '1.2.3.4' -DatabaseName 'myDB' -ApplicationDatabaseCredentials $databaseCredentials -force ; Write-Host 'Conversion done'; . 'c:\run\SetupDatabase.ps1'; " }))
can I make use of the credentials somehow? the original SetupDatabase.ps1 does as well ;)
The way it works is that your SetupDatabase is called instead of the original setupDatabase. You have all variables that are available in the original SetupDatabase available as well. You can also decide NOT to call the original and do the job yourself - then you are in 100% control.
jo,jo, I get that :) But I was apparently too stupid to make use of the scriptblock/hashtable/array style of injecting an "alternative" SetupDatabase.ps1...
In the end as simple as that:
-myScripts @( @{ "SetupDatabase.ps1" = 'Write-Host ''Converting database''; Invoke-NAVApplicationDatabaseConversion -DatabaseServer $databaseServer -DatabaseName $databaseName -ApplicationDatabaseCredentials $databaseCredentials -force; Write-Host ''Conversion done''; . ''c:\run\SetupDatabase.ps1'';' })
Awesome, thanks for the help!
Hi,
Hope you are ready for the weekend! Because I am, man ... so ready. You won't believe it.
I was working an a "shift-upgrade": shift services from onPrem to Containers and Upgrade the given BCv21 to a BCv23. I wanted to keep the SQL Server. So I moved along with the Instructions from BC on how to Upgrade a solution. "easy - can do this with both eyes closed and one hand behind my back..." ha.... I was so wrong :D
I fwd now a bit. I ended up in BCv23 Container connects to the DB, wants to call the Import-EncryptKey and crashes...because: Invoke-NAVApplicationDatabaseConversion is missing , the DB is not yet ready.... as the container as such was up, I jumped right into it and executed the commands manually...just to find out: I was trapped! you can not call Convert if there is no encryptKey and you can not call encyrptkey if the convertion has not taken place.
I double ffwd now: When I get home I have to fix the dishwash.... ah that was too far...a bit back: So what I think what I missed and did wrong was: my BCv21 DB needs to have an encrypt Key imported before I push it into the upgrade path with a container (or alternative: use a BCv21 container to do Upgrade steps 1-4 (as it will not miss the convert) )there it will also establish an Import-EncryptKey such that a follow up Bcv23 upgrade "just" works....). While I really would read a bit more about the logic behind that flow in bch - as it is also reusing keys?
So, what about the question now? Even with all that flow in place, I ended up with bccontainer Bcv23 connecting to a BCv21 DB is not working "directly" as it will detect the at one point the Conversation is missing .... I had in mind that bch can handle that (read about it at least in another issue here I think)... or is this only the case if you work with backup files? I do know about the "extend the scripts" logic in bch, but as always with this "events" hard to find the one fitting. Help is welcome!
At the end! it works now, but if I could get rid of the manual jump into a broken bc container, to do one command, and to rerun again the container creation script after that - would be really nice :)