Array in an array

[bplus]

In terms of an Array in an Array, if the index could work with decimal values, theoretically you could create an array of multiple layers making say the whole numbers the name of the student and decimal values could associate with that student. For example all .5 could carry attendance, all .9 carry math test score etc. The expansion could be limitless. But it doesn't work. Here is my attempt 

Code: (Select All)

Dim Shared TestArray(1.1 To 2)

For x = 1 To 2 Step .1
    TestArray(x) = x
Next

For x = 1.1 To 2: Print TestArray(x);: Next
Print
Print TestArray(1.1)
Print TestArray(1.2)
Print TestArray(1.3)
Print TestArray(1.4)
Print TestArray(1.5)
Print TestArray(1.6)
Print TestArray(1.7)
Print TestArray(1.8)
Print TestArray(1.9)
Print TestArray(2)

The results provide only 1.4 or 1.9. Why I don't know.

Arrays use integer indexes mult everything by 10 or 100 and you might be in business.

But you are no where near array in an array.

What is so hard imagining an array specially of numbers can be contained in a fixed length string?

[SpriggsySpriggs]

Is it just a flex that people are always trying to write up databases in QB64 rather than just use database tools to make and edit databases? If someone plans on putting some of this code out in a "production" environment, it might be well worth their time and give them some peace of mind to use something that's tried and true rather than being responsible for not only making the database, but also making all the code that maintains it. This might sound like a SQLite or MySQL plug and it is. Database queries are not hard and don't have to be. If I want all grades for a student from the year 2023? "SELECT * FROM Gradebook WHERE FirstName = 'Balderdash' AND LastName = 'Poppycock' AND Year = '2023'"
Boom. Now you've got everything pertaining to that student for that year. Oh, you also want to know the average for his grades? "SELECT AVG(PercentGrade) FROM Gradebook WHERE FirstName = 'Balderdash' AND LastName = 'Poppycock' and Year = '2023'"
What's that? You want to update his grade for History? "UPDATE Gradebook SET LetterGrade = 'A' WHERE FirstName = 'Balderdash' AND LastName = 'Poppycock' AND Subject = 'History' AND Year = '2023'"
Obviously, I've simplified that gradebook logic down a bit to show basic usage but it really is that easy. Now you don't need some crazy binary file with records and fixed length strings to emulate arrays and some handwritten algorithm for accessing, reading, and writing all that nonsense. Someone is going to ask me to give an example of MySQL but the Wiki example has worked and does still work. It's not the best, but it does work. If there is enough interest in making your lives easier and doing databases the right way, I'll possibly make a post explaining in detail how to do SQL. From the ground up. The whole 9 yards. From the software installations to the database creation to the database connection to the client configuration to the basic query usage.

Before I'm reminded that I promised a SQL tutorial back on the old forum, I know. I know.

P.S. SQLite would be better suited for a local application that will not need to keep all the information centralized. If you want a server to host the data, use MySQL.

[mnrvovrfc]

Is it just a flex that people are always trying to write up databases in QB64 rather than just use database tools to make and edit databases? If someone plans on putting some of this code out in a "production" environment, it might be well worth their time and give them some peace of mind to use something that's tried and true rather than being responsible for not only making the database, but also making all the code that maintains it.

But it's boring that way LOL, to some of us who are still trying to sharpen our programming skills, whether or not we get paid as programmers. At one time, it was fun using dBase until version 4 which wrecked the hard disks of the old IBM PC XT's some cheapskate college still insisted on. It was fun using this program I purchased, obviously created with Borland Pascal which had a nice GUI (was MS-DOS program in "SCREEN 0"). What a shame I couldn't go further with either after a few months. I couldn't even write a decent program in dBase language, while watching for long enough one of the computer science teachers doing it while working on the school roster. "Give me the dot," once he protested after he fixed something. LOL. (The interactive mode of dBase had the "dot" prompt.)

Programming in BASIC might be easier than programming for SQL, while most queries wouldn't be as complicated as it is usually with businesses everyday. I know next to nothing about what goes on in those transactions. What I know is that interpreted BASIC didn't have UDT's and therefore maligned for insisting on strings to hold numeric data for random access. That changed with QuickBASIC v4 I think, and the UDT's, it transformed what people thought about doing databases with a general-purpose programming language. It might have been better, however, if M$ went further with ISAM than VBDOS, or something else to encourage database programming to give SQL a run for its money.

Some people might protest that it might be great if QB64(PE) supported an object-oriented programming style, in order to have methods to operate on data, which looks sensible from the point of view of databases. But then getting fancy with polymorphism, templates and stuff like that isn't cool if somebody like this topic's starter desires to keep it fast and simple...

[madscijr]

Some people might protest that it might be great if QB64(PE) supported an object-oriented programming style, in order to have methods to operate on data, which looks sensible from the point of view of databases. But then getting fancy with polymorphism, templates and stuff like that isn't cool if somebody like this topic's starter desires to keep it fast and simple...

I agree that approaches like polymorphism are overkill and a headache.

For me, the main benefit of supporting simple objects (no crazy polymorphism) would be compatibility with calling & using OO COM type APIs for things like starting up an instance of Excel and controlling it from BASIC.

I think most people do not want or need OO. Having a data structure that _resembles_ a JavaScript object (but is not really OO - no classes or methods, just a more powerful UDT) where you can have nested arrays / arrays of objects / objects nested in objects / etc., and easily access each data element at any level with a string key using simple dot notation, and be able to serialize/deserialize the whole thing to/from JSON that can be read/written to/from a file, would be very powerul, while still keeping things simple for the programmer in the spirit of BASIC.

A SQL database with a server is useful if you have a lot of values to share between users on a network and want to run queries, sort values, filter data, etc. In cases where you're just loading in values from the local filesystem, making some changes, and saving them back to the file, I think using JSON keeps things nice and simple. 

Also, a JavaScript type nested data structure gives us a way to easily work with objects that come back from systems like REST Web services, without needing the language to be true OO. And that ability to interface with REST services will make QB64PE very useful for a lot of things.

That's just my take at this point!

[SpriggsySpriggs]

I think you might have missed me mentioning SQLite, which resides locally. Not as a networked database. And would actually be easier than trying to implement JSON, which is designed for object-oriented programming. Since all you need is a two dimension array, SQL is much easier. Also, the functions for SQL handle the data gathering for you. Tell me which is easier: Looping through a file yourself and trying to parse data with hand-written functions or using something that is used by many successful software products and when you want data, you just ask for it with very simple language and suddenly it's in your array.
Do
If....
If....
If....
If....
Loop Until....

OR

"SELECT * FROM myTable WHERE myColumn = 'myValue'"
For X = Lbound(DB_Results) to Ubound(DB_Results)
do something
do something else
Next

I really do not think you see how difficult managing JSON with QB64 will be. Sure, some poor soul might write up some 10,000 line library from scratch for doing it but the user experience will be absolute garbage. I've managed to use a bit of a JSON library in QB64 before but it was just a crappy experience and made me regret wasting the time on it.

[madscijr]

I think you might have missed me mentioning SQLite, which resides locally. Not as a networked database. And would actually be easier than trying to implement JSON, which is designed for object-oriented programming. Since all you need is a two dimension array, SQL is much easier. Also, the functions for SQL handle the data gathering for you. Tell me which is easier: Looping through a file yourself and trying to parse data with hand-written functions or using something that is used by many successful software products and when you want data, you just ask for it with very simple language and suddenly it's in your array.
Do
If....
If....
If....
If....
Loop Until....

OR

"SELECT * FROM myTable WHERE myColumn = 'myValue'"
For X = Lbound(DB_Results) to Ubound(DB_Results)
do something
do something else
Next

I really do not think you see how difficult managing JSON with QB64 will be. Sure, some poor soul might write up some 10,000 line library from scratch for doing it but the user experience will be absolute garbage. I've managed to use a bit of a JSON library in QB64 before but it was just a crappy experience and made me regret wasting the time on it.

The way you're describing working with JSON sounds a lot like my experiences with XML, and that user experience IS garbage. My experience with JSON objects was entirely different. To illustrate I'd need to sit down at the computer & write pseudocode for a proper example, but forget the If If loop until. That DOES suck! What I am talking about is more something like: 

Vacuum(MyHouse.Bedroom.Floor)
SearchRoom(MyHouse.Bedroom)
For pCount = lbound(Planets) to ubound(Planets)
    ThisPlanet = Planets(pCount)
    For pMoon = lbound(ThisPlanet.Moons) to ubound(ThisPlanet.Moons)
        ThisMoon = ThisPlanet.Moons(pMoon)
         If ThisMoon.Radius > MinSize and ThisMoon.Bases.Count < MaxBases Then blah blah

That's a lame example, but the point is that you aren't looping like in XML to find the property you're looking for, because you just use dot notation to directly access those properties. The programmer isn't "managing JSON" - that's done by a JSONify (deserialization) function one time, when you load it into memory. In fact, you don't even use JSON unless you're loading/saving persisted values. Different use case.

Hey, I don't need convincing on the value of SQL - in another life, I wrote T-SQL & PL/SQL sprocs every day as a part of my job, and I was quite fond of it. I just don't see SQL and JavaScript objects as competition for one another. JSON has its uses - including interoperability with REST services. How are you going to work with an object some http service sent back using SQL? Totally different tools for different jobs, with some overlap.

For me one issue with relying on SQLite is reliance on a 2nd product. Now the developer and their user have to download, install and set up a 2nd tool, so you might not be managing JSON (which needs no managing to begin with) but you're now managing a dependency, and moving away from the "one and done" simplicity that makes QB64/PE such a pleasure to use. 

But I don't want to poop all over SQL, it does have its merits and strengths. I'm just more of a mind to say why not both, and use whichever one fits the need? JSON type objects and relational databases each have their own strengths and uses. 

Let me back up a second though - you found a JSON library for QB64? Do tell!

[mnrvovrfc]

I agree with one thing. If the programmer is familiar with SQL, then go for it. If he/she is better at programming in SQL than in BASIC or some other general-purpose language then I agree with Balderdash, just go for it instead of bothering with a different language. Otherwise, learning SQL, when someone (like me) knows the most about BASIC dialects is another learning curve for somebody at least 50 years old. It should have been mentioned earlier. I'm not against SQL or any other programming method of doing things, especially about data storage and management. But I resist it because I'm not familiar with it. I could possibly sit down right now with M$ Visual Studio and use Visual Basic for some simple programs.

Possibly, because I also resist OOP LOL but it's one of my tendencies. I tried, I really tried to practice with Freebasic and like the ability to overload subprograms and functions but there was a time where I had to raise my hand and say, "Forget it!" For the same reason I had to abandon OOP in Turbo Pascal v5.5 and v6 which made me sad. I remember the day I bought Turbo Pascal v6 which came in a couple of 5-1/4-inch floppy disks. A few months later became disgusted with Turbo C++ with its syntax-coloring, and sometime later Turbo Pascal v7 was out which made my purchased copy look dull only because I couldn't use it effectively enough.

[mnrvovrfc]

I really do not think you see how difficult managing JSON with QB64 will be. Sure, some poor soul might write up some 10,000 line library from scratch for doing it but the user experience will be absolute garbage. I've managed to use a bit of a JSON library in QB64 before but it was just a crappy experience and made me regret wasting the time on it.

It has probably been attempted many times with XML which could be terrible depending on the implementation. I have been able to kludge simple programs that fabricated an SVG file. It had to be "Plain SVG" format saved by Inkscape, not "sodipodi" because I didn't want to get too much into those details. As a result I was able to do only simple line-drawing stuff. No problem, I created programs to do some gradients difficult to do inside that application. Also did a parser for XRNI and XRNS formats to load into RENOISE music-creation application. Each one is a ZIP file which contains an XML file and related FLAC or WAV files which are the samples used in the instrument or in the song. There was a significant difference in the document format for the song between v1.9 and v2.8 of RENOISE. In the later program version it was better most of the time to use the Lua scripting device inside that program to fiddle around with pattern (like triggering MIDI notes and their attributes) data.

Also I've tried to write a random-preset generator worth sharing for Zynaddsubfx, focusing on only one generator, first on the "additive" synth, and then on the "sub" synth which didn't have as many features. It was quite easy to make the "sub" synth sound horrible. I liked the results with the additive synth although the triggered sounds were samey. The XML required for that was a fantastic mess and had to follow along closely with where the program expected to find certain fields and sections. Also, the program had to be instructed to save a XIZ file (don't remember suffix now) entirely in text format, because saving to ZIP-compressed or other binary document was possible.

I know less about JSON, only that thing about quoting Kanye West LOL. But some scripts that I saw look much simpler than anything XML. It looks like a bunch of records being initialized here and there because some fields are records, or some other data item which requires special treatment (like the "CDATA" block of XML). I'd take that readability any day over XML.

[vince]

yeah, why learn arithmetic when calculators exist?

[SpriggsySpriggs]

SQLite isn't something you install. It's always provided with the software packages as a DLL. Because that's all you need. Before someone chimes in about Linux, you can make your program distribution install SQLite for the user if that's what's required. Installers exist, folks. Not everything has to be some mess that makes the user seek out ways to locate and install dependencies.

@KiloManjaro
I really feel like there is some misunderstanding of SQL going on here. Its mostly natural language, especially when dealing with small databases with only a few tables. If you can understand BASIC then you should be able to understand SQL. They both take a natural language approach.