Re: SQL and other databases

2011-03-22 Thread Peter Haworth
That's an excellent point. I'm so used to SQLite's type tolerance that I will have to be sure to validate data more carefully for MySQL usage. Pete Haworth On Mar 22, 2011, at 8:33 PM, Björnke von Gierke wrote: > A main difference (especially coming from LiveCode) is that you do not need > t

Re: SQL and other databases

2011-03-22 Thread Björnke von Gierke
A main difference (especially coming from LiveCode) is that you do not need to type the columns in SQLite. this means you can just dump anything anywhere, similar to how you can put any kind of data into any container in LiveCode. For mySQL, one would always need to do a lot more of sanitising,

Re: SQL and other databases

2011-03-22 Thread Bob Sneidar
I mean that sqLite is just a file on the local hard drive. If they were benchmarking mySQL running locally, I guess it's sort of the same thing, but mySQL still uses the networking protocols right? I mean you have to connect via localhost or the IP of the local machine, so it's still using netwo

Re: SQL and other databases

2011-03-22 Thread Peter Haworth
Not sure what you mean by "file based". Seems perfectly fair to me if I'm comparing using SQLite and MySQL on my local computer. I'm not recommending one above the other, just pointing out what I've read. As with any software, you should use what works best for your application. Pete Haworth

Re: SQL and other databases

2011-03-22 Thread Bob Sneidar
I don't think this is a fair comparison. sqLite is file based, and is likely going to be a local file at that. Of course that would be faster. Bob On Mar 22, 2011, at 12:26 PM, Peter Haworth wrote: > Definitely feature-deprived in some areas for sure but still very capable > DBMS, depending

Re: SQL and other databases

2011-03-22 Thread Bob Sneidar
Then it may be engine specific. My query produced an error when trying to create a table in my On-Rev database if I specified a default for varchar columns without using NOT NULL. After adding NOT NULL it worked fine. Bob On Mar 22, 2011, at 12:21 PM, Peter Haworth wrote: > Not seeing it on

Re: SQL and other databases

2011-03-22 Thread Peter Haworth
Definitely feature-deprived in some areas for sure but still very capable DBMS, depending on what your needs are. I haven't got round to benchmarks yet (and probably won't), but I've read several things on the web that suggest SQLite is much faster than mySQL. Of course if SQLite is missing a

Re: SQL and other databases

2011-03-22 Thread Peter Haworth
Not seeing it on those types either: `testdefault` char(10) DEFAULT 'XYZ', `testdefault2` varchar(10) DEFAULT 'ABC', Worked fine for me (through Sequel Pro). I wonder if this is a difference between versions of MySQL. I'm using the Community version which is the free one. You're right on the

Re: SQL and other databases

2011-03-22 Thread Bob Sneidar
Yes but those are numeric data types. The restriction was on the char types char() and varchar() (if I am not mistaken). TEXT types do not allow defaults at all according to the manual. Bob On Mar 22, 2011, at 10:29 AM, Peter Haworth wrote: > Hi Bob, > I'm slowly putting together a list of d

Re: SQL and other databases

2011-03-22 Thread stephen barncard
Having delved into LITE for about 5 minutes and only using MY the last few years I had the impression that LITE was a feature-deprived version of MYSQL. Thanks for reporting. On 22 March 2011 10:29, Peter Haworth wrote: > Hi Bob, > Stephen Barncard San Francisco Ca. USA more about sqb

Re: SQL and other databases

2011-03-22 Thread Peter Haworth
Hi Bob, I'm slowly putting together a list of differences between SQLite and MySQL. I'm concentrating on things that SQLite allows and MySQL does not. I haven't looked at extra functionality provided by MySQL over and above what SQLite provides since right now I just want to get to the point t

Re: SQL and other databases

2011-03-21 Thread Peter Haworth
Right, I'm slowly getting to grips with this. So far, I've discovered that table names/column names should be enclosed in back ticks not double quote characters and that SQLite AUTOINCREMENT = mySQL AUTO_INCREMENT. Weems like all my tables are being created once I make those changes. Next st

Re: SQL and other databases

2011-03-21 Thread Bob Sneidar
I may have mentioned in passing in another post, I use MySQLWorkbench. If you copy/paste the sequel to create the table into the query browser, you will get a red X to the left of the offending line, and the part that is wrong will be in another color than the "good" sql. It's pretty easy to see

Re: SQL and other databases

2011-03-21 Thread Peter Haworth
Thanks Bob, that's a good start. I'll search for the post with the link to differences. I hope you're right that my queries will all still work fine. tRight now, I'm struggling to get the database created. I was hoping I could export the db structure using the Firefox SQLite manager and then

Re: SQL and other databases

2011-03-21 Thread Bob Sneidar
Hi Peter. Well I don't have a complete listing because I am finding them out as I go. My current project gets the SQL to create a table from the sqlite_master table, then massages it to create the same table in mySQL. MySQL uses SELECT CREATE TABLE to get this information. One gotcha is that

Re: SQL and other databases

2011-03-21 Thread Peter Haworth
Bob, I'm about to make the leap from sqlite to mySQL so I'm very interested in the differences you mentioned. I think I've seen some of them in posts on the list here but any chance you could summarise them? I guess I am expecting some functional improvements in mySQL over sqlite since sqlite

Re: SQL and other databases

2011-03-21 Thread Bob Sneidar
Hypercard began to slow down tremendously once you got past 1000 cards. People began to experience index corruption not long after that. Stacks could become unreadable and unrepairable. The promise of SQL as I recall was to be able to have a standard query language that worked with foreign da

Re: SQL and other databases

2011-03-20 Thread Peter Haworth
Ditto to all that. The Rev manual section 2.2.8 talks about when to use a database. Their rule of thumb is to go database when you have more than 2000 records or need to allow multiple users to access/update information at the same time. Pete Haworth On Mar 20, 2011, at 1:57 PM, Kee Nethery

Re: SQL and other databases

2011-03-20 Thread Kee Nethery
> So, I am really interested to know why so many folk seem interested in using > Livecode to write database front-ends rather than using Livecode for the > database as such. 1. We already have a multiuser database and several other light client systems that access it via web browsers. I have a

SQL and other databases

2011-03-20 Thread Richmond
Maybe I'm a bit naive when it comes to databases, but I have all the children and their parents and so on, in a database that consists of a Livecode stack and nothing else. But then, in 1989 I had all the kids at Madrasa Emirat al-Khasa school, Al Ain, UAE in a database written and run on my BBC