Timm Motl / Tsunami....where are you??

[mark pruitt]

Hey Gary, that would be helpful. My email address is in my signature. Thanks again.

[Gary Stout]

Mark,

As I recall, the Tsunami demo would generate test data, but there was no way to tell it how many columns. From what I remember, it was last name, first name, address, city, state and zip. Might has also been a record number in there. If that information would be helpful, I can try to locate the demo (I should still have it around somewhere). It is basically gonna be comma delimited text.

Let me know if that will work for your test....

Gary

gary at sce4u dot com

[mark pruitt]

Hello..........Again

Cheerio everyone, I was looking for Tsunami (actually, the TRM site), couldn't find it, search PB forums, and found this post.

What I was particularly interested in was the feature Tsunami had that allowed you to create "data" records, so I could use the records to load an SQL database I'm working on for testing purposes.

Does anyone know where I can obtain a set of data (would prefer 50,000 plus records, at least 12 columns per record) for testing purposes?

If you know where something like this can be obtained, please assist the "data challenged"!

[Mike Doty]

Let us all know how he is doing.

[Vincent van der Leun]

Am e-mail has been sent to all active members of the Tsunami Users Group. If you did not receive one but want to, send me an e-mail directly.

I was not an active member, but was very interested in the product nevertheless... can I request an e-mail too?

I truly hope you are doing allright.

[Timm Motl]

Am e-mail has been sent to all active members of the Tsunami Users Group. If you did not receive one but want to, send me an e-mail directly.

[Brian Chirgwin]

No word yet on my end.

Nothing here either.

[Bern Ertl]

No word yet on my end.

[Gary Stout]

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.

Gary

[Joe Byrne]

Has anyone received an email from Timm yet? I'm curious to know if this is the end of Tsunami or if the next release will see the light of day.

[Bern Ertl]

I was just going to ask if anyone knew what was happening with Tsunami/Timm. I'm hoping for some good news about v3.7...

[Timm Motl]

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.

Best Regards,

Timm Motl

timm <at> trm-ug <dot> com

[Gary Stout]

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.

Mike,

Thanks for your explanation also! Its all starting to make sense. I can see now why this is the database of choice.

[Mike Doty]

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.

[Joe Byrne]

Can one SQL database have multiple tables?

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.

[Edwin Knoppert]

Sqlite is a supurb thing.
Unf. i never had any use for it, in the future a may abandon my designer's fileformat for sqlite though.

Sqlite also allows 100% custom encryption meaning, no data can be recognized from the file which may indicate it is an sqlite db file.

[Gary Stout]

Gary,

You're on the right track!

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.

Thanks again for the info!

[Joe Byrne]

Gary,

You're on the right track!

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!

[Gary Stout]

Thanks for the tips Paul!

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

Thanks Joe!

[Paul Squires]

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.

Joe has started a wiki for SQLitening. Check out this entry: http://www.sqlitening.com/wiki/index...e=Fundamentals

Once you go SQL it is hard to go back to traditional flat file/procedural type processing.