You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
I have been trying all day to check the Tsunami website and I get an error saying something to the effect the "no website exists at this location".
Maybe he is updating something on his site.... I hope.
Gary
Could be, or maybe someone forgot to renew the domain name
While I GREATLY appreciate the work Tim put into Tsunami, and Don into TTDS, its been a really, really, long time since anything new has happened with it. That's not bad, because frankly, the product has been rock solid.
However, the bigger reality is that most commercial products that don't have an SQL based database are taking big chances. I wrote a HUGE vertical application and lost the bid on a rewrite (expansion of the business model) when they asked what tools they could get to tap into the database. They weren't happy to hear that it would have to be something custom written, even if I gave it to them for free.
I learned my lesson there. Just about that time, Paul Squires was talking about the open source SQLite database. I followed that closely and when it became SQLitening, I was hooked. The learning curve really wasn't that big...just 2 main concepts to get my head around, the rest was easy. I've converted a number of Tsunami based apps to SQLitening now. Having worked with SQL, I wouldn't consider anything else now.
I understand where you are coming from. I am in the midst of a project now that should probably be a good candidate for an SQL type database based on the way I need to be able to search for records.
I just haven't taken the time to get a grasp on SQL. I tried and gave up on Tsunami several times and finally just dug in and learned it....now looking back, it really wasn't that hard. I am sure SQLitening would be about the same.
What do tables compare to say in Tsunami or a flat file database?
I think I had read somewhere that each row in a table was equal to 1 record.....that makes sense. Is the table equivalent to the entire database?
Maybe with a little push this stuff will all start making sense
Once I discovered SQLite I was hooked. It is so small but so incredibly powerful as well. It is perfectly suited for the type of small to mid size applications that I develop. It is also simply to install (there is no install!!), just copy a couple of DLLs to your applications' directory.
I had looked at Joe's site when he first announced it, but hadn't been back there. It looks like he has added a lot of good information since I was there last.
I will bookmark it this time
A 'row' is equivalent to a 'record' in Tsunami. A table contains groups of rows (records) and would be the same as a 'database' in Tsunami. A SQL database is a collection of tables. Tables are usually related in some form, but they certainly don't have to be.
SQL is extremely flexible. You can index anything, but even if you don't have an column (field) indexed, you can still use it with very a little performance hit. For example, if you had a record that contained member information and you wanted a member to 'log in', assuming your login names were unique, all you'd have to do to valid the login is something like this:
slSEL "SELECT MemberID FROM MemberTable WHERE LoginName=" + Login$ + " AND Password = " + PW$
Assuming you have the two columns (fields) LoginName and Password in your table (record), the user would enter the values for Login$ and PW$ and your 'SELECT" statement would either be true or false. If true, then you can pull out the value of MemberID for that user! You don't have to read the record first, then compare the values.
Lets say that in program you need the members phone phone, but the home phone is not part of the same 'table' your working in. No problem. Rather than doing two reads to two separate tables, you could do something like this:
slSEL "SELECT * FROM MemberTable, HomePhone.MemberINfO, WHERE MemberID = " + MemberID$
This grabs ALL the data (fields) from the table (record) in the MemberTable table (database) AND the member's home phone from the Table "MemberINFO". The resulting data would appear to you as if HomePhone were just another field in your record even though it exists in an entirely different table (database)!
There are a number of ways to combine data from different tables, and a zillion ways to read the data in any format you want. Try this on for size:
slSEL "SELECT * FROM MemberTable ORDER BY accessdate"
No matter how your table (database) is initially sorted, the resulting data would give you all the member records sorted by the last access date! No ARRAY SORT after reading through the data... just select and process!
The thing that stumped me at first was the 'Record Set' concept which is how you access the data once you've issued a query (read), but it really won't take long to figure out how that works. Everything else is amazingly logical.
Feel free to poke around the Wiki Paul mentioned, as well as visiting Paul's forum at www.PlanetSquires.com for further info and help. SQLitening is by far the best database I've used with PB yet, and I think I've used them all, literally.
Oh, BTW, I don't know if its been pointed out that one of the 'improvements' SQLitening offers over the standard SQLite DLL is the ability to access your databases remotely. The same functionality that TTDS gives Tsunami. If you are on a closed network, you can simply store your databases in a shard folder and access just as if they were local, but if the network is slow, or you need to cross a router (if your 'server' is accessible on the Internet for example), the Remote functionality of SQLitening will take care of it nicely. You can even mix and match modes and not have to change a single line of code. Therefore, its easy to make a 'single user' and 'multi-user' version of your program with the same code file. The only difference is whether or not you issue one command at the beginning to establish a remote connection or not!
A 'row' is equivalent to a 'record' in Tsunami. A table contains groups of rows (records) and would be the same as a 'database' in Tsunami. A SQL database is a collection of tables.
Tables are usually related in some form, but they certainly don't have to be.
Thanks Joe.....your comments certainly answers many of the questions I have had and definitely sounds like the direction I need to be moving in.
Your comparison to SQL terms and Tsunami terms helps a bunch also. I now have a better overall understanding.
One more question that arose from reading this post.....you mention a SQL database is a collection of tables......Can one SQL database have multiple tables? Would this be similar to more than one Tsunami database within the same file name???
I sure do like the search capabilities you mentioned. The project I am working on now is going to require searches based on date ranges.....could be a complete year or a portion of any given year. It seems like this would be easier in SQL than anything else I have used yet.
Sure thing. The 'database' adds one more container level over what Tsunami does. So a single database can hold lots of tables...never really checked to see what the limits are, but I'm sure its hundreds at least.
The tables usually have something in common which gives them the relationship aspect. In my example above, the memberID would have to exist in both tables but you could have tables totally unrelated to any other if you wished. This is where the idea of set numbers comes in with SQLitening. This is a value that indicates which table is returning the data to you... so to speak.
One more question that arose from reading this post.....you mention a SQL database is a collection of tables......Can one SQL database have multiple tables? Would this be similar to more than one Tsunami database within the same file name???
A database is a single file containing all the tables.
Two tables can not have the same name.
Think of a table as a file.
Tables can be created/dropped and indexed on the fly.
It is an incredible system.
It is even possible to attach a database to another database.
I sent Timm an email yesterday and didn't get a response.
The trm-ug.com is still down, today.
The Tsunami website has been taken down. An e-mail will be sent to current members of the Tsunami Users Group to explain why (believe me, there's a very good reason). Support for existing Tsunami users will still be available via e-mail, but no new memberships are being accepted (again, for a very good reason).
I can't say more about it here, but you'll known what's going on soon enough.
No word here. I hope Tsunami will continue. It has been a very reliable product and I am looking for to the possible client/server version that Timm mentioned.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Comment