Invisible wrote:

> 
> MySQL isn't transactional = I'm not really interested.
> 
> 

What is it, you are trying to do?  In English please, not feature babble.

Post a reply to this message

Tom Galvin wrote:
> Invisible wrote:
> 
>>
>> MySQL isn't transactional = I'm not really interested.
>>
>>
> 
> What is it, you are trying to do?  In English please, not feature babble.

"Transactional" is a very basic functionallity for any product claiming 
to be a "database".

Basically it's very difficult to design a system such that multiple 
users can access the data at once, and yet not screw it up. This hard 
problem is one of the many things a database is supposed to solve. So a 
database that fails to solve this problem doesn't really interest me 
very much.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

47626794@news.povray.org...
> "Transactional" is a very basic functionallity for any product claiming to 
> be a "database".

Actually it really depends on the purpose of the database. Read-only 
databases that get updated twice a year or single-user databases may not 
require transactional abilities at all.

G.

Post a reply to this message

Gilles Tran wrote:

>> "Transactional" is a very basic functionallity for any product claiming to 
>> be a "database".
> 
> Actually it really depends on the purpose of the database. Read-only 
> databases that get updated twice a year or single-user databases may not 
> require transactional abilities at all.

Ultimately, I guess it depends on your definition of "database".

Under certain definitions, a CSV file is a database. There are people 
who develop "in-memory databases", yet under some definitions there's no 
such thing. (Since some definitions require "recoverable" and "robust".)

For the thing I'm trying to do, transactional (and recoverable, etc) is 
very important. If I was trying to catelog my CD collection, MySQL would 
probably be quite a good fit...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> Tom Galvin wrote:
>> Invisible wrote:
>>
>>>
>>> MySQL isn't transactional = I'm not really interested.
>>>
>>>
>>
>> What is it, you are trying to do?  In English please, not feature babble.
> 
> "Transactional" is a ..
> 

BABBLE, BABBLE

WHAT are you trying to do?  It's a very simple question.

Post a reply to this message

Tom Galvin wrote:

> BABBLE, BABBLE
> 
> WHAT are you trying to do?  It's a very simple question.

I'm going to build [yet another] helpdesk application.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Thu, 13 Dec 2007 13:05:47 +0000, Invisible wrote:

> Does anybody here know anything about ODBC?

Yes. :-)

Jim

Post a reply to this message

Invisible wrote:
> For the thing I'm trying to do, transactional (and recoverable, etc) is 
> very important. 

I think your info about mysql is out of date.

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message

Invisible wrote:
> Tom Galvin wrote:
> 
>> BABBLE, BABBLE
>>
>> WHAT are you trying to do?  It's a very simple question.
> 
> I'm going to build [yet another] helpdesk application.
> 

Then mysql is more than adequate to the task.

Why not use a helpdesk that already exists, uses mysql, is available 
under the gpl, and is cross platform.

http://www.oneorzero.com/

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> For the thing I'm trying to do, transactional (and recoverable, etc) 
>> is very important. 
> 
> I think your info about mysql is out of date.

Well, last I checked, MySQL is a "toy database" on a par with Access. 
(Do they even support nested SELECT statements yet?) There's nothing 
"wrong" with that, it's just not the type of product I'm looking for.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message