|
How about a web-based, IBM PC emulator with an EARLY Norton Utilities release (back when it was good!).
Be sure to check out what's on drives C: and D:. Very interesting.
Norton Utilities 2.00 | PCjs Machines[^]
|
|
|
|
|
|
I want to step back in time to the days when:
- I thought politicians were honest
- I thought the Government knew what it was doing
But I don't think my parents would want me. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
It would be no different. Because you thought politicians were honest and you thought the Government knew what it was doing. 
|
|
|
|
|
But then I was young and innocent and had all of my life before me. Now I'm not so young, definitely not innocent, and most of my life is behind me. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Wordle 700 4/6
🟨🟩🟩⬛⬛
⬛🟩🟩⬛🟨
⬛🟩🟩🟩⬛
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 700 6/6
🟨⬜⬜⬜⬜
⬜🟨🟨⬜⬜
🟨⬜🟩🟨⬜
⬜🟩🟩🟩⬜
🟩🟩🟩🟩⬜
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 700 4/6
⬛⬛🟩⬛⬛
🟨⬛🟩⬛⬛
🟩🟩🟩🟩⬛
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 700 4/6*
🟨⬜⬜🟩⬜
⬜🟩🟩🟩⬜
🟩🟩🟩🟩⬜
🟩🟩🟩🟩🟩
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
⬜⬜🟩⬜⬜
⬜⬜🟩⬜🟨
🟨⬜🟩⬜🟨
⬜🟩🟩🟩⬜
🟩🟩🟩🟩⬜
🟩🟩🟩🟩🟩
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 700 5/6
🟨🟩⬛⬛⬛
⬛🟩🟩🟩⬛
⬛🟩🟩🟩⬛
⬛🟩🟩🟩⬛
🟩🟩🟩🟩🟩
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
Wordle 700 4/6
⬜⬜⬜🟩⬜
⬜⬜🟩🟩⬜
⬜🟩🟩🟩⬜
🟩🟩🟩🟩🟩
crept up on it
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
SQL is the simply best language... for those situations it's suited for.
But when a situation requires another technique, SQL is simply the worst language. 
Yup, I'm gonna have to use C# for this in hopes that it can handle this transform more betterishly.
|
|
|
|
|
Indeed. I wrote a project here called Reggie that generates matching code for TEXT and NTEXT data such that you can use regular expressions with your database inputs.
The generated code is awful in terms of what it has to make SQL do. Encoding ASCII or 16-bit Unicode into UTF-32 to work with the generated regex engine - plus just the nastiness of returning results (as rowsets of course). It's not navigable code - at least not for mortals.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I wrote CLR functions for doing security several different things including Regular Expressions.
Never try to do string manipulation in SQL.
modified 20-May-23 10:00am.
|
|
|
|
|
I did it to demonstrate an extreme use case for a templated based regex code generator I wrote.
It wasn't really meant to be practical, but illustrative, in that if you could make it generate SQL code, you could make it generate just about anything.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: I did it
Why does it not surprise me?   
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
honey the codewitch wrote: It wasn't really meant to be practical, but illustrative, in that if you could make it generate SQL code, you could make it generate just about anything.
Ah, can it generate TECO?
|
|
|
|
|
What is TECO?
To err is human. Fortune favors the monsters.
|
|
|
|
|
I've noticed that many people and/or companies think that SQL is somehow easier than programming.
I've even worked for a company where you were automatically a "SQL consultant" if you didn't know how to code.
Recently, I picked up a project for a company with 10K(!) procedures mostly written by a guy who didn't know how optional parameters work.
The result is that I've found plenty of simple front-ends with "SQL back-ends".
Basically a simple web app that just executes stored procedures on GET and POST requests.
The stored procedures are usually written by "IT professionals", "consultants" and managers.
The problem with working like this, SSMS is not an easy tool that formats your code (format is always terrible!), where you can search and debug or where you easily implement DevOps practices.
Completely unmaintainble.
|
|
|
|
|
Ah, yes, the "everything must be in a procedure" crew.
Also watch out for the "only DBAs can write SQL" crew.
|
|
|
|
|
PIEBALDconsult wrote: Also watch out for the "only DBAs can write SQL" crew.
Well in my experience it tends to lean way in the other direction. Without someone with some database experience they will not even attempt anything in the database except simple CRUD. Which of course ends up producing some really inefficient code.
|
|
|
|
|
jschell wrote: CRUD
PTUI. Don't even use that term around me. No one with proper database skills thinks in such limited terms.
My best experiences were where I would write the SQL and a DBA would point out improvements which could be made.
|
|
|
|
|
Sander Rossel wrote: companies think that SQL is somehow easier than programming
Well 'technically' that is true.
For the most part, especially the way companies use it the vast majority of time ANSI SQL is not that difficult.
However PL/SQL, TSQL, etc are not in fact ANSI SQL.
Nor for that matter is database design, optimization, etc.
Sander Rossel wrote: The problem with working like this,
Not sure where you are going with this.
Bad code is just back code. Bad designs are just bad designs.
The language is not the problem for either of those.
And ignorance of those problems certainly is not the fault of the language.
Sander Rossel wrote: Basically a simple web app that just executes stored procedures on GET and POST requests....The stored procedures are usually written by "IT professionals", "consultants" and managers.
But for most businesses, most of the code should in fact be simple. It should not require much more than that. It is pointless that everyone be a database DBA because there is generally no need for the expertise all of the time. So there will be some stored procs because that is all that is actually needed.
|
|
|
|
|
jschell wrote: For the most part, especially the way companies use it the vast majority of time ANSI SQL is not that difficult.
True, but when it comes to complex business logic, SQL is really not the best tool for the job.
jschell wrote: Not sure where you are going with this.
SQL just isn't the tool to build complex systems with loops, if-then-elses, XML and JSON parsing and generation, and even sending out emails.
I've seen stuff like writing to table variables within a transaction so that the data can be written outside of the transaction even when the transaction is rolled back... Or using temp tables because the table should be used across procedures, but still within a transaction while not losing the data on a rollback... Stuff of nightmares really.
And if that's what you're going to do with SQL it becomes very difficult very fast.
And there's just no way to debug all this unless you're going to set breakpoints (which isn't straightforward and will block your entire server, I've never actually seen anyone doing this besides myself).
Just because you can doesn't mean you should.
So yeah, I'm talking about actual programming in SQL (with all the limitations that come with it).
jschell wrote: But for most businesses, most of the code should in fact be simple.
If you're running a multi billion multinational the code is never simple.
These are some of the customers I've seen this method of working.
jschell wrote: It is pointless that everyone be a database DBA because there is generally no need for the expertise all of the time.
True, but these companies have their complex business logic written in SQL by people who don't even have the professional courtesy to format their code.
These people have never written code because they're not coders.
They're more accustomed to one-off scripts and that's how they write their not-so one-off SQL too.
Last week I met someone who had never seen a CREATE TABLE script and who didn't know how to write an UPDATE from the top of his head, and he maintains over 10K of stored procedures 
I even met someone once who opened a new query window by right clicking on a table and creating a DROP TABLE script, he then deleted the script and so he had an empty query window
He was kind of surprised when I yelled "NO WAIT!" (this was on a production server) and I was even more surprised when he told me he always opened a query window like that.
I then showed him the new query button.
These people shouldn't even be allowed near a database, yet here they are, developing and maintaining huge databases for huge companies.
And my point is, these applications shouldn't be developed in SQL in the first place, but when it is, it should at least be developed by people with proper training.
And if you need people with proper training you might as well hire developers and pick the right tool for the job.
But I guess there's two things at play here, the Dunning-Kruger effect and when all you have is a hammer every problem looks like a nail.
So we have someone who completely overestimates his SQL knowledge and now every problem is solved using SQL.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
