« first day (4250 days earlier)      last day (915 days later) » 

00:14
SQL Server is learning English?
 
1 hour later…
01:18
Slowly
01:28
FORTRAN has simpler syntax
Might flatten the learning curve
If that's the goal, of course
Which it probably isn't
@PaulWhite pattern matching. 😒
Regex[p]es are not far behind, one might imagine
I guess everything were a mistake
01:57
They really should have killed the first person who tried to sort seashells.
 
4 hours later…
05:59
Morning
@jcolebrand I'm no consultant, just a mere DBA, but here are my two cents.
Morning
@jcolebrand you might be interested in this
https://www.youtube.com/watch?v=XDwXPXsdNN4
Why not have the schema definitions in the program? When a version 0.9 of the application starts (for the first time), it goes along and checks the database according to some internal or external (txt file) information to determine if the current version of the database is compatible with the application.
If not, the application will trigger a mechanism that updates the database to meet the requirements of the 0.9 version of the application. Subsequent applications logging in to the database perform a simple version number check in the database and will start faster than the first application that connected.
This concept allows for a wide distribution of different versions of the application, which can be updated from version 0.9 directly to 1.2 or in smaller increments, because the current definition of the required database (schema) is distributed together with the verison of the applicaiton. Either in the applicaiton or in a supplied text filetion.
Works on Citrix (central database), Stand-alone (single seat), Stand-alone (centralised database), Docker images, etc.
The application:
... compares the database version/schema with the application version
... triggers any required updates to the schema of its database
... allows for verious versions of the application to be running in different setups
It doesn't work if you have different versions of the application running in the same location connecting to a centralised database. Here you will have to have some application packaging and distribution in place to ensure that all clients connect with the same application version of the central database OR you disallow older applications to connect to the database if the version does not match the required database version.
 
3 hours later…
09:26
@jcolebrand this discusses a similar procedure: docs.gitlab.com/ee/development/database/…
 
3 hours later…
12:25
@jcolebrand Morning is this dbms-specific? I.e. SQL Server? If so, a common way of automating schema updates is via Microsoft's sqlpackage.exe with a model of the desired database state. At app setup, you spawn sqlpackage to bring the database into the desired state.
We use it for applying changes to QA/UAT/Prod regularly.
13:10
A chairde - Morning all!
@JohnK.N. I'll turn that comment into an answer this evening - fair enough? :-)
13:48
@ErikDarling Ah, yes, the infamous shell sort.
grug think boog no guess what shell rock under. grug bet boog four mammoth boog wrong.
14:41
@Vérace Thanks.
Morning
 
2 hours later…
17:10
> Not a happy camper???
17:44
Either a happy non-camper or an unhappy camper.
 
1 hour later…
18:54
The abundance of bugs rarely makes a happy camper.
Campers are thereby requested to apply debugging solutions.
 
2 hours later…
21:15
@JohnK.N. There are a number of problems with allowing an app to deploy its own database changes at runtime, some of which are outlined here: EF Core - Applying Migrations - Apply migrations at runtime
That's specific to EF Core and migrations, but most of them apply more broadly.

« first day (4250 days earlier)      last day (915 days later) »