Does anybody here know anything about ODBC?

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

Post a reply to this message

Invisible wrote:
> Does anybody here know anything about ODBC?
> 

run away run away

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message
news:47612e2b$1@news.povray.org...
> Does anybody here know anything about ODBC?
>

Open Database Connectivity.

A standard API for connecting to various forms of data sources. Generally
slower than OleDB, but easier to find drivers for more esoteric systems.

Was there anything specific you wanted to know?

Post a reply to this message

Gail Shaw wrote:

> Open Database Connectivity.
> 
> A standard API for connecting to various forms of data sources. Generally
> slower than OleDB, but easier to find drivers for more esoteric systems.
> 
> Was there anything specific you wanted to know?

There appear to be ODBC drivers for accessing CSV files and so forth.

So does that mean I can perform arbitrary SQL queries on a CSV file?

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

Post a reply to this message

Tom Austin wrote:

> run away run away

So-noted.

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

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Does anybody here know anything about ODBC?
>
I know a bit. There are probably others here who know more.  A more specific
context would probably be helpful.  Are you looking to learn more about the
subject in general? Is there a specific problem you need to solve?

A reasonably short and to the point intro can be found here:
http://www.unixodbc.org/doc/ProgrammerManual/Tutorial/

Best Regards,
Mike C.

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message
news:476132a3$1@news.povray.org...

> There appear to be ODBC drivers for accessing CSV files and so forth.

Yup. Excel spreadsheets, xml files, assorted databases, active directory,
etc...

> So does that mean I can perform arbitrary SQL queries on a CSV file?

Probably. How complex a statement depends on the capabilities of the driver
in question. If it has a manula/help file, read it.

Post a reply to this message

Gail Shaw wrote:
> "Invisible" <voi### [at] devnull> wrote in message
> news:476132a3$1@news.povray.org...
> 
>> There appear to be ODBC drivers for accessing CSV files and so forth.
> 
> Yup. Excel spreadsheets, xml files, assorted databases, active directory,
> etc...
> 
>> So does that mean I can perform arbitrary SQL queries on a CSV file?
> 
> Probably. How complex a statement depends on the capabilities of the driver
> in question. If it has a manula/help file, read it.

...right. So you're saying the type of queries I can do can vary by ODBC 
driver?

I guess I was assuming that an ODBC driver is like a graphics driver - 
either you have graphics or you don't. (Oh, and some of the more exotic 
features might not be available, like 3D acceleration or hardware overlays.)

Basically I want to develop a program that talks to a database. I was 
going to use ODBC to do this. But I don't have a database set up right 
now, so I was wondering if I could test it with a simple text file until 
I get round to setting up a real database. [Obviously a CSV file isn't 
going to even approach the speed of a half decent database engine. But I 
can test whether data goes in and data comes out.]

Alternatively, does anybody know how to configure PostgreSQL? Because I 
can't get the damn thing to work properly...

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

Post a reply to this message

"Invisible" <voi### [at] devnull> a écrit dans le message de news: 
47614210$1@news.povray.org...
> Basically I want to develop a program that talks to a database. I was 
> going to use ODBC to do this. But I don't have a database set up right 
> now, so I was wondering if I could test it with a simple text file until I 
> get round to setting up a real database. [Obviously a CSV file isn't going 
> to even approach the speed of a half decent database engine. But I can 
> test whether data goes in and data comes out.]

You can do some limited database work with text files (or Excel files etc.), 
but that will mostly be limited to actions that can be done without 
requiring indexes, i.e. SELECT and INSERT statements rather than UPDATE and 
DELETE for instance. For testing a database, you'll need a database. MS 
Access will do, and MySQL takes a couple of minutes to install on a PC.

G.

Post a reply to this message

Gilles Tran wrote:

> You can do some limited database work with text files (or Excel files etc.), 
> but that will mostly be limited to actions that can be done without 
> requiring indexes, i.e. SELECT and INSERT statements rather than UPDATE and 
> DELETE for instance. For testing a database, you'll need a database. MS 
> Access will do, and MySQL takes a couple of minutes to install on a PC.

PostreSQL also takes a couple of minutes to set up. Unforuntately, I 
can't make it do anything once it's installed.

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

Maybe I'll just use M$ Access. [Obviously that means I can only use 
computers which have M$ Access.]

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

Post a reply to this message

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

It is if you use InnoDB engine tables. Note, it's about five times 
slower, but it's transactional.

-- 
   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

Darren New wrote:
> Invisible wrote:
>> MySQL isn't transactional = I'm not really interested.
> 
> It is if you use InnoDB engine tables. Note, it's about five times 
> slower, but it's transactional.

Last I heard, it's transactional yet still not 100% ACID-compliant.

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

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message
news:47615af1$1@news.povray.org...
>
> Maybe I'll just use M$ Access. [Obviously that means I can only use
> computers which have M$ Access.]
>

No, you just need the access ODBC driver (which comes with the standad MDAC
package) You'll need a copy of access to create the database, you don't to
access the file over ODBC (or OleDB).
Not sure about the licencing implications, but I'm guessing you aren't too
concerned about that either.

Other option you can try is to download SQL Server Express. It's limited in
size of DBs it can handle, but is fine for testing.
If you download the management studio pack as well, you get a nice GUI
frontend for it. Otherwise you'll have to access it through command line

Post a reply to this message

Gail Shaw wrote:

>> Maybe I'll just use M$ Access. [Obviously that means I can only use
>> computers which have M$ Access.]
>>
> 
> No, you just need the access ODBC driver (which comes with the standad MDAC
> package) You'll need a copy of access to create the database, you don't to
> access the file over ODBC (or OleDB).
> Not sure about the licencing implications, but I'm guessing you aren't too
> concerned about that either.

Hmm, interesting.

So you're only paying for the GUI frontend, but the database engine? (If 
indeed it warrents the term "engine"...)

> Other option you can try is to download SQL Server Express. It's limited in
> size of DBs it can handle, but is fine for testing.
> If you download the management studio pack as well, you get a nice GUI
> frontend for it. Otherwise you'll have to access it through command line

Or, alternatively, you can apparently download the full version of 
Oracle for free - provided you promise to never ever use it "for real", 
only "for test purposes". Apparently. And I already know how to work 
Oracle...

But yes, Access would probably be much simpler just for test purposes.

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

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message
news:476160fb@news.povray.org...
>
> > Other option you can try is to download SQL Server Express. It's limited
in
> > size of DBs it can handle, but is fine for testing.
> > If you download the management studio pack as well, you get a nice GUI
> > frontend for it. Otherwise you'll have to access it through command line
>
> Or, alternatively, you can apparently download the full version of
> Oracle for free - provided you promise to never ever use it "for real",
> only "for test purposes". Apparently. And I already know how to work
> Oracle...

You can get a full version of SQL server for $50, feature equivalent to
Enterprise edition, just not licenced for production usage. Only really
worthwhile for people who work with SQL a lot.

I know there's a free version of Oracle, wasn't aware it was all the
features of the top version..

SQL Express is a restricted feature set, but it can be used anywhere,
including on production systems, free.

Post a reply to this message

Gail Shaw wrote:

> I know there's a free version of Oracle, wasn't aware it was all the
> features of the top version..

Yeah. I was surprised too. But, apparently, when you "buy" Oracle they 
send you a "media kit" that contains all the products, but only license 
you to install the one you paid for. Hmm, I wonder how they can tell?

> SQL Express is a restricted feature set, but it can be used anywhere,
> including on production systems, free.

I plan to use PostgreSQL for the final thing, or maybe Oracle, but right 
now I just wanna test. ;-)

-- 
http://blog.orphi.me.uk/

Post a reply to this message

Invisible wrote:
> Darren New wrote:
>> Invisible wrote:
>>> MySQL isn't transactional = I'm not really interested.
>>
>> It is if you use InnoDB engine tables. Note, it's about five times 
>> slower, but it's transactional.
> 
> Last I heard, it's transactional yet still not 100% ACID-compliant.

Well, no, but it's transactional. The A and I and D parts, I think.  I'm 
not sure whether it has support for the C part, since it insists on 
having defaults for every data type, so things like declaring a column 
"not null" and not providing a value isn't an error.

-- 
   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

Gail Shaw wrote:
> SQL Express is a restricted feature set, but it can be used anywhere,
> including on production systems, free.

I'll note that the features that are restricted are performance 
features, not SQL features as such. E.g., it'll only process one request 
at a time, only run on one core, won't do hot backups, stuff like that. 
But in theory anything you write on "real" SQL Server will run without 
change on SQL Express, as long as timing isn't an issue.

I used SQL Express in one project I did where other things (wireless 
bandwidth, primarily) kept us down to a couple of transactions a second, 
and it worked fine.

-- 
   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:

> 
> 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

"Invisible" <voi### [at] devnull> a écrit dans le message de news: 
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

Tom Galvin wrote:

>> I'm going to build [yet another] helpdesk application.
>>
> 
> Then mysql is more than adequate to the task.

I disagree.

> Why not use a helpdesk that already exists, uses mysql, is available 
> under the gpl, and is cross platform.
> 
> http://www.oneorzero.com/

I'll take a look. It's probably too complicated though. (Needs to be 
something a 4 year old can play with and not break.)

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

Post a reply to this message

"Orchid XP v7" <voi### [at] devnull> wrote in message 
news:4763b9d9$1@news.povray.org...
> Tom Galvin wrote:

> I'll take a look. It's probably too complicated though. (Needs to be 
> something a 4 year old can play with and not break.)
>
Something that looks like the image here?
http://www.jupiterimages.com/popup2.aspx?navigationSubType=itemdetails&itemID=22191158

;oD


-- 
-Nekar Xenos-

Post a reply to this message

"Orchid XP v7" <voi### [at] devnull> wrote in message
news:4763b9d9$1@news.povray.org...
> Tom Galvin wrote:
>
> >> I'm going to build [yet another] helpdesk application.
> >>
> > Then mysql is more than adequate to the task.
>
> I disagree.

Why is it not? What features do you need that the latest MySQL doesn't
support?

Post a reply to this message

Nekar Xenos wrote:

>> I'll take a look. It's probably too complicated though. (Needs to be 
>> something a 4 year old can play with and not break.)
>>
> Something that looks like the image here?
>
http://www.jupiterimages.com/popup2.aspx?navigationSubType=itemdetails&itemID=22191158
> 
> ;oD

LOL! Might be a bit beyond their mental capacity... ;-)

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

Post a reply to this message

Gail Shaw wrote:
> "Orchid XP v7" <voi### [at] devnull> wrote in message
> news:4763b9d9$1@news.povray.org...
>> Tom Galvin wrote:
>>
>>>> I'm going to build [yet another] helpdesk application.
>>>>
>>> Then mysql is more than adequate to the task.
>> I disagree.
> 
> Why is it not? What features do you need that the latest MySQL doesn't
> support?

I'm sure MySQL is great if you just want to catelogue your CD 
collection. But if you're going to have multiple people access it at 
once, you need transactions or you'll end up with a data integrity 
nightmare.

(In this instance, it also needs to be possible to back up the database 
without shuting it down. And to recover if there's a crash. And all 
those other kinds of things.)

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

Post a reply to this message

"Orchid XP v7" <voi### [at] devnull> wrote in message
news:4763b965$1@news.povray.org...
> 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.

MySQL is a database service, unlike access. It supports multiple users
without the data files becoming corrupt every second day.

Access data files don't require anything applications installed to use them,
so they're very handy for data storage in single-user desktop applications

> (Do they even support nested SELECT statements yet?)

As of MySQL 4.1. Two versions before present

Post a reply to this message

"Orchid XP v7" <voi### [at] devnull> wrote in message
news:4763c335$1@news.povray.org...

> I'm sure MySQL is great if you just want to catelogue your CD
> collection. But if you're going to have multiple people access it at
> once, you need transactions or you'll end up with a data integrity
> nightmare.

OK, now I'm sure you're having us all on.
Where on earth did you get the idea that mySQL can't handle multiple
concurrent users?

http://dev.mysql.com/doc/refman/5.0/en/transactional-commands.html

http://dev.mysql.com/doc/refman/5.0/en/innodb-transaction-model.html

And note that's version 5.0. Latest is 6.0

> (In this instance, it also needs to be possible to back up the database
> without shuting it down. And to recover if there's a crash. And all
> those other kinds of things.)

http://dev.mysql.com/doc/refman/5.0/en/backup.html
http://dev.mysql.com/doc/refman/5.0/en/backup-strategy-example.html
http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html
http://dev.mysql.com/doc/refman/5.0/en/table-maintenance.html

Tell, me. Did you do any research on mySQL before making these claims?

Post a reply to this message

On Sat, 15 Dec 2007 14:31:24 +0200, "Gail Shaw" <initialsurname@sentech sa dot
com> wrote:

>Tell, me. Did you do any research on mySQL before making these claims?

Does Andrew ever research anything before asking?
Remember p.o.t. is your friend :)

Regards
	Stephen

Post a reply to this message

Gail Shaw wrote:

> Tell, me. Did you do any research on mySQL before making these claims?

I heard that MySQL is this cool free database that's taking over the 
world. The KNOPPIX CDs contain it, so I thought I'd sit down and have a 
play.

I was expecting great things. Maybe too great. What I actually found is 
that by default "commit" and "rollback" are no-op, and transaction 
handling is an "optional feature" that you have to explicitly enable.

I decided that any database that considers something so fundamentally 
important to be "optional" is obviously not a very serious effort. Then 
I looked at the release notes and it says "yay! we now support unions", 
and I'm like "my God - you're kidding, right?"

At that point, I lost interest.

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

Post a reply to this message

"Orchid XP v7" <voi### [at] devnull> wrote in message 
news:4763b965$1@news.povray.org...
> 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*


AAARGH !!

Post a reply to this message

Orchid XP v7 wrote:
> Well, last I checked, MySQL is a "toy database" on a par with Access. 

As I said, your info is out of date. You're about four major releases 
behind. Now they have distributed clusters and everything. Kind of 
"start simple and work up to something worth using."

It still has annoying features, but "toy" it isn't.

-- 
   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

Orchid XP v7 wrote:
> once, you need transactions or you'll end up with a data integrity 
> nightmare.
> 
> (In this instance, it also needs to be possible to back up the database 
> without shuting it down. And to recover if there's a crash. And all 
> those other kinds of things.)

Damn you're dense. :-) Really. MySql does all that sort of stuff. 
Indeed, I have a process that monitors the hot spare every 30 seconds 
and tells me if it gets more than 60 seconds behind the live master. My 
read-only heavy queries run against the hot spare instead of the live 
read/write database. I'm doing financial transactions that need to audit.

Really. Your information is at least 5 years out of date. You're 
complaining that you just wish Windows supported true multitasking.

-- 
   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

Orchid XP v7 wrote:
> I was expecting great things. Maybe too great. What I actually found is 
> that by default "commit" and "rollback" are no-op, and transaction 
> handling is an "optional feature" that you have to explicitly enable.

Honestly, of the 30 or so tables currently in my application, there's 
about 5 that need transactional consistency. I don't need it in the 
debugging logs. I don't need it in the (equivalent of) web access logs. 
I don't need it in the tables that's collecting the real-time feeds off 
the various partners, nor off the custom hardware. Those are all 
append-only (for the most part) tables.

But where I need it, I turn it on, and take the penalty of speed over 
correctness.  Enforcing transactions is high overhead if you don't need 
it. If all your table write-accesses are to a single row, why would you 
want to lock things?

-- 
   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

Darren New wrote:

> Honestly, of the 30 or so tables currently in my application, there's 
> about 5 that need transactional consistency.

Well, my application will probably only be about 5 tables, and it's 
simple enough that speed is unlikely to be a problem. So why make things 
more difficult than necessary?

> But where I need it, I turn it on, and take the penalty of speed over 
> correctness.  Enforcing transactions is high overhead if you don't need 
> it. If all your table write-accesses are to a single row, why would you 
> want to lock things?

Why do you need to lock things to enforce transactional integrity? 
Locking is only one (suboptimal) way to solve the problem.

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

Post a reply to this message

Orchid XP v7 wrote:
> Well, my application will probably only be about 5 tables, and it's 
> simple enough that speed is unlikely to be a problem. So why make things 
> more difficult than necessary?

Then use the innodb table type, and be happy.

> Why do you need to lock things to enforce transactional integrity? 
> Locking is only one (suboptimal) way to solve the problem.

The RDBMS locks things to enforce transactional integrity. I don't do it 
explicitly. I merely start a transaction, and the appropriate rows get 
locked.

Whatever you do to enforce transactional integrity? It takes resources.

-- 
   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

Darren New wrote:
> Orchid XP v7 wrote:
>> Well, my application will probably only be about 5 tables, and it's 
>> simple enough that speed is unlikely to be a problem. So why make 
>> things more difficult than necessary?
> 
> Then use the innodb table type, and be happy.

It just worries me that the designers of this system fundamentally think 
that transaction integrity is so unimportant that it's not even the 
default, that's all.

>> Why do you need to lock things to enforce transactional integrity? 
>> Locking is only one (suboptimal) way to solve the problem.
> 
> The RDBMS locks things to enforce transactional integrity. I don't do it 
> explicitly. I merely start a transaction, and the appropriate rows get 
> locked.

That's only one way of implementing transactional integrity. (And, IMO, 
not a very good way.)

> Whatever you do to enforce transactional integrity? It takes resources.

Now that at least is a valid statement.

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

Post a reply to this message

"Orchid XP v7" <voi### [at] devnull> a écrit dans le message de news: 
47642e2a$1@news.povray.org...
> It just worries me that the designers of this system fundamentally think 
> that transaction integrity is so unimportant that it's not even the 
> default, that's all.

It's not the default because it's not needed in many database applications. 
Frankly, it looks like you just discovered the word "database" yesterday, 
fell in love with a couple of buzzwords even though you still have strictly 
no idea about what a database it and how it works (this thread started about 
*** CSV files *** being used for testing your database). Sorry mate, but you 
can't spout utter nonsense about MySQL and Access being "toys" and be taken 
seriously after that. Get some experience first.

G.

Post a reply to this message

Orchid XP v7 wrote:
> Gail Shaw wrote:
> 
>> Tell, me. Did you do any research on mySQL before making these claims?
> 
> I heard that MySQL is this cool free database that's taking over the 
> world. The KNOPPIX CDs contain it, so I thought I'd sit down and have a 
> play.
> 
> I was expecting great things. Maybe too great. What I actually found is 
> that by default "commit" and "rollback" are no-op, and transaction 
> handling is an "optional feature" that you have to explicitly enable.
> 
> I decided that any database that considers something so fundamentally 
> important to be "optional" is obviously not a very serious effort. Then 
> I looked at the release notes and it says "yay! we now support unions", 
> and I'm like "my God - you're kidding, right?"
> 
> At that point, I lost interest.
> 
There is a difference between stating that a program can not do 
something and asking the p.o-t for their opinion and experience. In 
practice the result here is the same, mainly because there are a lot of 
friendly people here that have com to know you over the years. IRL your 
mileage may vary. One of the main differences IRL is that the former 
tends shuts down all communication, while the latter invites the other 
to participate in an exchange of ideas.

Post a reply to this message

Darren New wrote:
> 
> Damn you're dense. :-) 
> 

He does program in Haskell.

Post a reply to this message

Gilles Tran wrote:

> Frankly, it looks like you just discovered the word "database" yesterday, 
> fell in love with a couple of buzzwords even though you still have strictly 
> no idea about what a database it and how it works (this thread started about 
> *** CSV files *** being used for testing your database). 
> 
> 

You forgot reinventing the wheel.

He's writing a helpdesk!  That's IT 101.


If it's for fun, that's one thing.  If it's to meet a business need, 
then put in one that has been tested, debugged and gained a little 
maturity.  Your users will thank you, and the person who takes the job 
after you will be deligheted not to inherit a undocumented 
haskell/oracle monster.

Post a reply to this message

Orchid XP v7 wrote:
> Tom Galvin wrote:
> 
>>> I'm going to build [yet another] helpdesk application.
>>>
>>
>> Then mysql is more than adequate to the task.
> 
> I disagree.

Hmmm who should I listen to? Gail the professional DBA, who is flown all 
over the world for database technology conferences, with many years of 
experience, or Andrew?  Sorry mate.



> 
> I'll take a look. It's probably too complicated though. 
> 

Glad you are so openminded.

Here's another one that runs on Active Server Pages with an MS Access 
Database or MS SQL backend.

http://www.liberum.org/

It's been running at major companies for years with great reliability 
and users love it.  Some people even modified it to use mysql.

Post a reply to this message

Orchid XP v7 wrote:
> It just worries me that the designers of this system fundamentally think 
> that transaction integrity is so unimportant that it's not even the 
> default, that's all.

Know something? The default is also to commit after every statement on 
most DBs too. So? :-)

Yes, MySql *started out* tremendously simplified. But it's like you're 
complaining about how DOS looses disk clusters if you don't close the 
file properly, while evaluating XP.

> That's only one way of implementing transactional integrity. (And, IMO, 
> not a very good way.)

Actually, I think there are a number of ways to do it, depending on the 
table. You can even use explicit locks to enforce at least the I of ACID 
on the non-transactional tables.

>> Whatever you do to enforce transactional integrity? It takes resources.
> Now that at least is a valid statement.

Yah. In my experience, it's about a 5:1 ratio. When I realized that, I 
changed most of my tables to non-transactional. There's nothing I'm 
running on the tables that isn't idempotent.

-- 
   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