I was working on an old old old "ERP" system written in D3 PICK. It's a database, programming language and OS all in one with roots in tracking military helicopter parts in the 1960's. I was working on it in the mid-2000s.
It had SQL like syntax for manipulating data, but it was interactive. So you would SELECT the rows from the table that you wanted, then those rows would be part of your state. You would then do UPDATE or DELETE without any kind of WHERE, because the state had your filter from the previous SELECT.
It has a fun quirk though - if your SELECT matched no rows, the state would be empty. So SELECT foo WHERE 1=2 would select nothing.
UPDATE and DELETE are perfectly valid actions even without a state...
Working late one night, I ran a SELECT STKM WHERE something that matched nothing, then before I realised I realised my state had no rows matched, I followed up with DELETE STKM.
Yep, the entire Stock Movements table four the last 20+ years of business were gone.
The nightly backup had not run, and I didn't want to lose an entire day of processing to roll back to the previous night.
I spent the entire night writing a program to recreate that data based on invoices, purchase orders, stocktake data, etc. I was able to recreate every record and got home about 9am. Lots of lessons learnt that night.
> if your SELECT matched no rows, the state would be empty
> UPDATE and DELETE are perfectly valid actions even without a state
Some may call this a fun quirk :) but I'd call it a horrible mistake in the design of the system! It should have been conceptually obvious to the designer that an empty set of rows is a perfectly valid state and is fundamentally different from "no state".
At university I had to use a programming language to do some specific calculations.
It was obviously designed by someone who had not taken any courses in formal languages, compilers and algorithms.
It had a fun quirk, the final result would change depending on which names you used for your variables.
When the phd student guiding our lab session told me to not use underscores in my variable names, I thought i'd humor her just to show her it was a stupid suggestion. But she knew more than me.
I remember when I was an intern at a large telco company, and an older woman who was VP of something or other called me into her office to answer some questions about what parts we needed based on supplies I had just inventoried.
I told her one, and she didn't recognize the part number, so she said she'd look at the distributor's website. I watched her go to google.com, type in the url, and then I "helpfully" interrupted to explain that the address bar was where urls went, and that google was for searching for other things. She proceeded to click the "view cached version" in the google results, and told me that distributor's website was down and this was her workaround.
I learned a lot from that job. Including when to keep my mouth shut!
A lot of older systems were like that before they became more commodity items with guard rails.
Some of the early SAN disk arrays used to use an assembly like config interface with no sanity checks, type in the wrong command and you could wipe the whole array.
The company I worked for at the time had a blanket policy that any change had to be implemented by the vendor to shift liability for any mistakes.
You're probably right, but back then it was assumed you knew what you were doing I guess. The old idiom of "Linux won't stop you shooting yourself in the foot" was even more true of this system.
>It's a database, programming language and OS all in one with roots in tracking military helicopter parts in the 1960's. I was working on it in the mid-2000s.
A friend of mine worked for a company repairing transmissions on drilling platforms. To say it was a specialty shop is an understatement. However, they had been in business for 40 years. While not a computer system from the 60s, theirs was a custom written solution from the 80s running on a DOS 286 PC. It was stuck on the top shelf of a closet with a UPS. The developer had long been "permanently" unavailable for at least a decade, and they were too scared to loose the data in having it rebuilt. I asked how scared, and the answer was "it's the only computer in the building with a UPS". I'm laughing at the insanity just retelling the story
Yep, the entire table. I figured since I had to write it to do the day at a minimum, doing the whole table would help me find corner cases and errors since it was a much larger range of data
he only recreated the ones not saved by the nightly backup, meaning he used the previous nightly backup and recreated from invoices the last ~23 hours.
Maybe I don't fully comprehend what you're saying... but is it even possible to do this?
I mean what if at some point particular entries were manually tweaked and the database was updated to fix an error in an invoice or something. And then you recreated data from what you assume is 100% reliable data.
I'm happy to try to understand if you don't mind simplifying the explanation.
I can't remember the specific details now (almost 20 years have passed!), but the STKM table was effectively a performance/convenience data store. Every bit of information was available from other transactional data, but in order to actually have a chronological historical view of "stock movements", it was maintained in this central table.
Probably compared their code's recreated table against the table from the day old backup.
If twenty years worth of data (up until two days ago) match, then the recreation of the missing day is probably fine too. It's not guaranteed of course, but...
Whe. I first learned SQL on an oracle cli client I was told to type begin; then any other command. For a brief while until i learned about transactions, I assumed that it was part of the cli startup :)
I deal with D3 pick and the fear I have of doing select bp and catalog bp is insane. The entire system is a mess so wiping the md would be catastrophic. :)
It had SQL like syntax for manipulating data, but it was interactive. So you would SELECT the rows from the table that you wanted, then those rows would be part of your state. You would then do UPDATE or DELETE without any kind of WHERE, because the state had your filter from the previous SELECT.
It has a fun quirk though - if your SELECT matched no rows, the state would be empty. So SELECT foo WHERE 1=2 would select nothing.
UPDATE and DELETE are perfectly valid actions even without a state...
Working late one night, I ran a SELECT STKM WHERE something that matched nothing, then before I realised I realised my state had no rows matched, I followed up with DELETE STKM.
Yep, the entire Stock Movements table four the last 20+ years of business were gone.
The nightly backup had not run, and I didn't want to lose an entire day of processing to roll back to the previous night.
I spent the entire night writing a program to recreate that data based on invoices, purchase orders, stocktake data, etc. I was able to recreate every record and got home about 9am. Lots of lessons learnt that night.