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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
20 matches
Mail list logo