There's tightly coupling and then there's this...
-
So I need to replace an old file import. The file is simple, it looks like:
40241018Some comment 123...
Where the first two characters is some ID, the next two is the year, next two month, next two day, next 16 a comment, next three a price, etc... That's not the exact file, but you get the idea, fixed width fields. Nothing fancy and usually very easy to read. Now the database has the following columns. ID BIGINT DATE CHAR(8) STATUS CHAR(1) FIELD01 CHAR(2) FIELD02 CHAR(2) FIELD03 CHAR(2) FIELD04 CHAR(2) FIELD05 CHAR(16) FIELD06 CHAR(3) ... Now let's just ignore all the uppercases, CHAR data types and the CHAR(8) for date... Naming the fields FIELDXX is a pain because now you'll never know what the data represents, but this may have been done for "flexibility"??? :confused: The real horror is the code. It gets the table structure of the database, skips the first three fields (because they're not part of the import), reads the length of the next field, takes that many chars and places it in the table :wtf: That means if you change the field length or even field order in the database your import will fail. Also, if the file changes in even the slightest way you'll have to change your database schema. This was probably the hardest way to make this work and for sure the most tightly coupled :doh: Why do people do this? :((
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
So I need to replace an old file import. The file is simple, it looks like:
40241018Some comment 123...
Where the first two characters is some ID, the next two is the year, next two month, next two day, next 16 a comment, next three a price, etc... That's not the exact file, but you get the idea, fixed width fields. Nothing fancy and usually very easy to read. Now the database has the following columns. ID BIGINT DATE CHAR(8) STATUS CHAR(1) FIELD01 CHAR(2) FIELD02 CHAR(2) FIELD03 CHAR(2) FIELD04 CHAR(2) FIELD05 CHAR(16) FIELD06 CHAR(3) ... Now let's just ignore all the uppercases, CHAR data types and the CHAR(8) for date... Naming the fields FIELDXX is a pain because now you'll never know what the data represents, but this may have been done for "flexibility"??? :confused: The real horror is the code. It gets the table structure of the database, skips the first three fields (because they're not part of the import), reads the length of the next field, takes that many chars and places it in the table :wtf: That means if you change the field length or even field order in the database your import will fail. Also, if the file changes in even the slightest way you'll have to change your database schema. This was probably the hardest way to make this work and for sure the most tightly coupled :doh: Why do people do this? :((
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
They do it because if work were easy it wouldn't be work, would it? *hides*
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
So I need to replace an old file import. The file is simple, it looks like:
40241018Some comment 123...
Where the first two characters is some ID, the next two is the year, next two month, next two day, next 16 a comment, next three a price, etc... That's not the exact file, but you get the idea, fixed width fields. Nothing fancy and usually very easy to read. Now the database has the following columns. ID BIGINT DATE CHAR(8) STATUS CHAR(1) FIELD01 CHAR(2) FIELD02 CHAR(2) FIELD03 CHAR(2) FIELD04 CHAR(2) FIELD05 CHAR(16) FIELD06 CHAR(3) ... Now let's just ignore all the uppercases, CHAR data types and the CHAR(8) for date... Naming the fields FIELDXX is a pain because now you'll never know what the data represents, but this may have been done for "flexibility"??? :confused: The real horror is the code. It gets the table structure of the database, skips the first three fields (because they're not part of the import), reads the length of the next field, takes that many chars and places it in the table :wtf: That means if you change the field length or even field order in the database your import will fail. Also, if the file changes in even the slightest way you'll have to change your database schema. This was probably the hardest way to make this work and for sure the most tightly coupled :doh: Why do people do this? :((
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
So I need to replace an old file import. The file is simple, it looks like:
40241018Some comment 123...
Where the first two characters is some ID, the next two is the year, next two month, next two day, next 16 a comment, next three a price, etc... That's not the exact file, but you get the idea, fixed width fields. Nothing fancy and usually very easy to read. Now the database has the following columns. ID BIGINT DATE CHAR(8) STATUS CHAR(1) FIELD01 CHAR(2) FIELD02 CHAR(2) FIELD03 CHAR(2) FIELD04 CHAR(2) FIELD05 CHAR(16) FIELD06 CHAR(3) ... Now let's just ignore all the uppercases, CHAR data types and the CHAR(8) for date... Naming the fields FIELDXX is a pain because now you'll never know what the data represents, but this may have been done for "flexibility"??? :confused: The real horror is the code. It gets the table structure of the database, skips the first three fields (because they're not part of the import), reads the length of the next field, takes that many chars and places it in the table :wtf: That means if you change the field length or even field order in the database your import will fail. Also, if the file changes in even the slightest way you'll have to change your database schema. This was probably the hardest way to make this work and for sure the most tightly coupled :doh: Why do people do this? :((
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I mean, at least they didn't call the db fields f1, f2, etc. See, they tried... :laugh: :laugh: :laugh:
Jeremy Falcon
