On Thursday, June 23, 2022 at 9:14:07 AM UTC-5, osuv... at gmail.com wrote:
> On Tuesday, June 21, 2022 at 12:08:21 AM UTC-4, Dave Froble wrote:
> > Way, way, back, it was determined that due to the lack of adequate channels in
> > Basic+, 12 to be precise, it would be advisable to have a single file that could
> > be used for different types of data. Things with just a few records, such as
> > maybe 20 terms codes, 50 state codes, and others. We even called it a "codes
> > file".
> That's the kind of thing SQLite is great at when used as what they call an
> application file format. MacOS uses it for several of their applications now,
> though they build the library without load extension capability.
No man. You need to find a copy of this book
https://www.theminimumyouneedtoknow.com/app_book.html
and read the section on multi-typed records. SQL of no flavor can do what we did back then. What I put in the book was the best I could remember from LIOCS Perspective software. There were quite a few other DEC VARS that took the same approach to the point of using the same record types. I "think" they all stole the same Singer BASIC code.
Been over a decade or more since I looked at the TOLAS stuff Dave helped create. CODES was multi-typed records exposed to too much Gamma Radiation combined with too much LSD.
Sometimes a CODES record had an actual value in it like a logical file name or something. Other times the "value" was a logic code. Customer orders for a customer with this CODES key calls this set of functions for processing/pricing. Oh, you have a different code, you go down a different path. The logic paths were in that CODES record.
Other times a CODES record told you what BASIC MAP to use to map the fields of a record.
Yes, I can hear Dave screaming already "No! No! You idiot! You've only got some of it right!" It's been more than a decade man and I've spend that decade making medical devices.
You simply can't do the bastardizations we did with RMS indexed files using any form of SQL.
LIOCS and everyone else who stole the Singer ERP software originally written in Singer BASIC
Every record would have the same primary key format. Here is a snipped from that book
Invoice:
Key 0:
Invoice number char 10 15 in system s written later.
Rec_type char 2
Sequence_no char 2 Sometimes called line number
Generic m ap with filler at the end for some amount.
Record types:
10 Invoice header
20 Bill to information
30 Ship to information
40 Carrier information
60 Invoice detail
61 Detail comment
62 Credit or discount line
70 Credit or discount summary
80 Invoice summary
The 70 and 80 record types are not that common.
For the world that evolved from the ashes of Singer . . .
PDP BASIC we had separate FLD$() routines for each record type.
BASIC/PLUS (was that when we first got MAP that allowed things like INV_NO$ = 2%, followed by the & in the right margin?) Anyway there would be one MAP (INV) declaration for each record type.
VAX BASIC we got RECORD types. We all got smarter and declared file level IO-ROUTINE modules for each file. I think we nested the %INCLUDE statements so there was one %INCLUDE that pulled in all of the different RECORD definitions. All OPEN/CLOSE/CREATE/KEYED HIT/SEQUENTIAL/error was handled in the IO-ROUTINE module. As long as you didn't forget to check for error things worked well.
RMS indexed files had the fantastic feature of "Key of reference". Once you performed a keyed hit via a key, it established a "key of reference." (not every x86-wanna-be-a-real-computer-one-day-when-I-grow-up platforms have any concept like this) Once you did a keyed hit for the 10 record, you could sequentially process the order/invoice/whatever until the primary number changed. The record types put everything in the proper order for printing, screen display, general processing, etc.
Now, layer CODES on top of this.
Dave, feel free to jump in and point out how little I remember of TOLAS.
At any rate, there is no SQL that will let you put multi-typed records in a table. The "best" you could hope for is to have the primary key fields then a BLOB object one had to hack like we did in BASIC. You would be right back to CVT$% and RSET logic. (Didn't they drop RSET and LSET from the DEC BASIC specification at some point?)