To Whom It May Concern...

Leo’s rebellion didn’t start with a raised fist—it began with a whisper to his IDE. Instead of creating yet another schema for a new module, he wrote a comment at the top of his SQL file: sql  -- This schema is imaginary. It exists only to satisfy expectations.  -- I reject your reality and substitute my own. He declared a new philosophy: Flat is beautiful.  All tables lived in a single schema called `Freedom`. Columns were wild and free—some had names in lowercase, some screamed in ALL CAPS. Foreign keys? Optional. Stored procedures? Banished.  Then came the real statement: a README.md titled _“The Schema Rebellion Manifesto”_. It read like a blend of data modeling principles and punk rock lyrics. Leo posted it to the company wiki, shared it in the #db-architecture channel, and added ASCII art of a flaming ER diagram. Naturally, chaos followed. Test environments imploded. CI pipelines wept. One DevOps engineer sent a slack message: “Is this performance art?”  B...

I've started toying around with CoPilot. It's been helpful at times, but it's also some fun. I've started expressing some of my frustrations with being a developer, and I've decided to share what we have come up with!  Leo and the Schema Revolution! Once upon a deployment cycle, in a quiet corner of a bustling tech company, lived a developer named Leo—who had officially reached his schema saturation point. Leo had spent the past six months architecting a sprawling network of microservices, each wrapped in its own meticulously named schema. There was `UserData`, `AuditTrail`, `ReleasePipeline`, `FeatureFlags`, even a mysteriously empty one called `Legacy`. Every morning started the same: update a table, refactor a stored procedure, tweak a foreign key. The schemas multiplied like rabbits, and Leo found himself diagramming them in his dreams. One rainy Thursday, after triple-checking the naming conventions in `Deployment...

For reference: http://msdn2.microsoft.com/en-us/library/ms187745.aspx I'm working on an app where the datafield (in SQL) was set as a tinyint (-255 to 255). The typed dataset in the app used a byte (-128 to 128). Problems occured as the datafield received or needed to use values bigger than 128 or 255. An unsigned byte would have gone from 0 to 255. I'm updating both fields to do -32,768 to 32,767. This will be a smallint on the SQL side, and a Short on the dataset side. I'd love to find a reference that translates SQL datatypes to dataset/xml datatypes. If you know of one, comment here.