November 18, 2020 at 12:22 am
thank you, Joe, for the COBOL info. I didn't know SQL was so impacted by COBOL. Yes, the display should be handled on the front end, instead of the database layer(unless it's via Agent Job, etc).
November 18, 2020 at 2:04 pm
"If it's so bad, Microsoft will improve on it, just as Microsoft fixed the notorious message 8152, "String or binary data would be truncated" for SQL 2016 SP2(+CU?) or later."
So you're saying we can look forward to FORMAT() function performance improving by 2040? 🙂
November 18, 2020 at 3:32 pm
could be earlier than 2040??. It's not slow to everyone. Just like table variable, after it was available, I adopted and in the end, I switched back to temp table, since it's extremely slow to me.
November 18, 2020 at 3:37 pm
no matter whether you like it or not, 1)application developers write managed code more; 2)application developers implemented the functions, including FORMAT, CONVERT, CAST, LTRIM, RTRIM, TRIM, LEFT, RIGHT; 3)FORMAT is more similar to the .net functions(Format, FormatDate, FormatNumber, etc) ; 4) more code will be generated by tools in the front end.
Yes, I get that. My point is that what's good for the application is not necessarily good for the database. If you're a developer, you need to know and practice the differences. Writing a post on an SQL Server forum that uses FORMAT isn't helping people understand those differences.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 18, 2020 at 9:35 pm
Everything we do today is affected by punchcards, and then by COBOL. Look at how 00 programming still assumes a procedural model.
Are you surprised that all animals have DNA? Axle symmetry? Well, maybe not octopuses; they seem to be a separate line of evolution. I've had the fun of trying to teach people who grew up with declarative procedural programming instead of functional, declarative programming.
Please post DDL and follow ANSI/ISO standards when asking for help.
November 18, 2020 at 11:54 pm
Everything we do today is affected by punchcards, and then by COBOL. Look at how 00 programming still assumes a procedural model.
Are you surprised that all animals have DNA? Axle symmetry? Well, maybe not octopuses; they seem to be a separate line of evolution. I've had the fun of trying to teach people who grew up with declarative procedural programming instead of functional, declarative programming.
For some reason, you insist that COBOL controls everything.
But relational theory? Nah, don't think so. I don't remember Dr. Codd ever mentioning COBOL when he introduced the idea of a data system based on the relational model. Did I just miss it? That's possible, I'm sure, but what would be the relevance??
Implementation of relational dbs? Maybe initially, but not so much today. Sure, COBOL has to have a way to use, but there are myriad ways to do that from within COBOL itself.
The vast majority of developers have never seen COBOL, let alone written it. Their procedural biases, where they do exist, likely come from Java, Phython, whatever, but not from COBOL. There aren't fixed columns to write code and comments in, for example.
Punch cards are even less relevant, since no one remembers them (or chooses never to think of them again, even if they know what they are). How do they effect SQL-based-languages (let's include T-SQL, PL/SQL and their equivalents, rather than just pure SQL statements) today?
In a lot of places, RPG (and VB and other BASIC variants) had more of a residual effect on today because of their extremely short field names. Some truly legacy systems transferred their 6-char names to columns. A royal pain to deal with. COBOL at least allowed long names.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
November 23, 2020 at 8:14 pm
>> For some reason, you insist that COBOL controls everything. <<
Not controls, but influences it. Strongly. Are you still using the Latin alphabet?
>> I don't remember Dr. Codd ever mentioning COBOL when he introduced the idea of a data system based on the relational model. <<
Actually Dr. Codd never mentioned computers. His RDBMS was very abstract. However, if you want to talk to some of the early SQL developers, then you'll find an awful lot of COBOL influence.
>> The vast majority of developers have never seen COBOL, let alone written it. Their procedural biases, where they do exist, likely come from Java, Phython, whatever, but not from COBOL. There aren't fixed columns to write code and comments in, for example.<<
I always get a laugh out of this, but when my younger friends chide me for not knowing whatever the language du jour, I asked them what they are developing. So much of it in the commercial world is using the new language to access old COBOL files! I don't know what the current figures are now, but COBOL used to have 80% of the world's commercial data, thanks to insurance, banking, finance, etc.
>> Punch cards are even less relevant since no one remembers them (or chooses never to think of them again, even if they know what they are). <<
You should have been in Prague to hear my Posgres user group talk on the curse of the punchcard. Model your data in records, and not Rows because of your mindset. Procedural code still dominates the mindset. As a quick example. Recently I saw a SQL Server posting about a procedure to create or validate a check digit. It had while loops. And it was being held up as a really nice way to write SQL Server code.
>> In a lot of places, RPG (and VB and other BASIC variants) had more of a residual effect on today because of their extremely short field names. Some truly legacy systems transferred their 6-char names to columns. A royal pain to deal with. COBOL at least allowed long names. <<
The six-letter names go back to FORTRAN and it began the "short name" mindset. I ought to know; I suffered from it. Even today I can rattle off at a dozen male person names that are exactly 6 letters long. 🙁 In particular, having grown up with Mad Magazine, I was very fond of using Melvin and Irving for dummy variables in my FORTRAN. Got to be such a habit. I didn't even realize I was doing it.
Please post DDL and follow ANSI/ISO standards when asking for help.
November 24, 2020 at 3:53 am
Why Microsoft released a less performant FORMAT function to make SQL server look bad? I am sure Microsoft released it from requests by SQL server community.
If it's so bad, Microsoft will improve on it, just as Microsoft fixed the notorious message 8152, "String or binary data would be truncated" for SQL 2016 SP2(+CU?) or later.
MS released it not by request from SQL community, but by request from .Net community. Because they more concern about ease of use of SQL for .Net developers then about integrity and performance of the product.
When they fix it - that would be the time to start recommending it.
But before that - don’t use or recommend it to anybody. Period.
_____________
Code for TallyGenerator
November 24, 2020 at 4:24 am
sterling3721 wrote:Why Microsoft released a less performant FORMAT function to make SQL server look bad? I am sure Microsoft released it from requests by SQL server community.
If it's so bad, Microsoft will improve on it, just as Microsoft fixed the notorious message 8152, "String or binary data would be truncated" for SQL 2016 SP2(+CU?) or later.
MS released it not by request from SQL community, but by request from .Net community. Because they more concern about ease of use of SQL for .Net developers then about integrity and performance of the product.
When they fix it - that would be the time to start recommending it. But before that - don’t use or recommend it to anybody. Period.
+1 million.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply