AAAAARRRRRGGGGGHHHHH
 

I have to vent. I'm having doubts v25 and the new server will ever see the light of day.

<rant on>

V25.5 is hanging randomly - a bear of a bug to track down. I finally got it to happen on my WinXP 64 system. The debugger shows the comm thread called the C runtime library to create a thread. That called GetModuleHandle (Kernel32.DLL); The main thread called LoadIcon. Deadlock. WTF!!! Do I have to put a mutex around all calls to the OS???!!!!

While I'm in a blue mood, let me give you my opinion of SQLServer 2000. Your data would be safer with a pack of thieves. Read a row, then try to update it - it will usually work. Put an update lock on the row as you read it, well that seems to improve your chances a bit - but still no guarantee. Try to get a pretty web report of your machines or assignments. Don't expect to see the same number of machines listed two times in a row. 30 assignments one time, zero the next, 18 a third time. Pick any isolation level you want - no joy. Bloody hell.

Now try to work on a user's bug report. Is there a bug in our PHP code that maintains the database. Maybe - or maybe its just another case where the database has deposited one of our INSERT, UPDATE, or DELETE statements in the great unknown. Scott has actually had to write (hopefully temporary) code that does an update, and if no rows are affected does it again. Sure, reliability goes up but what kind of solution is that?

<rant off>

SQLServer 2005 supposedly has a new isolation level called "consistent snapshot". Maybe it will help, or maybe it will introduce a whole new set of problems, headaches, and impossible situations.

[QUOTE=Prime95;116897]Do I have to put a mutex around all calls to the OS?[/QUOTE]Strange behaviour there. Of course WinXP OS is supposed to be completely thread safe. GetModuleHandle/LoadIcon seems an unlikely combination to deadlock the process.

One thing you might like to try that avoids the C create thread causing a deadlock is to create all threads once only at program startup (with a mutex in operation if you like). Just kind of park them in a pool. Each time you want a thread for something, simply set the RIP and ResumeThread.

As for SQL uglyness, I have no sugestion, but perhaps MySQL or SQLite could be better? I've so far managed to avoid all databases so it's just a shot in the dark, not an endorsement of either.

I would advise against sqlite since it has performance issues. My experience with MySQL has been good so far but then I've never had millions of exponents to deal with.

[QUOTE=garo;116981]I would advise against sqlite since it has performance issues. My experience with MySQL has been good so far but then I've never had millions of exponents to deal with.[/QUOTE]I'm quite satisfied with PostgreSQL. It's what my employers ([url]www.flybase.org[/url]) use to hold a massive database of most everything that is known about Drosophila genetics. A current FB database runs to about 12Gbytes, so PostgresQL iseasily capable ofhosting moderately sized databases. I can also recomend MySQL as that is what's behind the FlyBase website search engines.

I run PostgreSQL on my home system too, though not yet for anything particularly substantial. I've dreams, eventually, on putting all my factoring data into a proper database but I've yet to dispel sufficient apathy to start on the task.

YMMV.


Paul

I can categorically advise you against using SQLServer 2000. The dirty little secret about it that nobody wants to talk about...
Memory Leaks.
Just sit back, let your database server run and you'll notice that after a few weeks your 500MB database is using over 3 Gigs. Or, you may not notice it until after the machine starts paging, but by then you'll notice the calls from users saying their application is frozen or hung when they try to push or pull data. I had never heard of a database server that ~required~ monthly reboots. I contrast this to one of my LAMP webservers that is happy to run multiple databases under MySQL, some up to almost 1 Gig, that runs happily months on end.

George,

Your rant brings back unpleasant memories. I'll add my voice to the chorus above: dump SQL Server 2000 if at all possible. SP4 fixed most of the memory leaks noted above, but the locking problems you mention are certainly there. Snapshots in SQL Server 2005 work much better. Nonblocking reads should be just the thing for your web reports.

That said, I too lean towards MYSQL. It is far more stable than the MS products, at least without full time care and feeding by a dedicated support staff. The only drawback I see is that there isn't as tight integration between MSVC and MYSQL as you get with SQL Server. If you want the full CLR/.NET stuff, building an app with the 2005 versions of MSVC and SQLServer is far quicker than the equivalent with MYSQL.

No experience with databases, but my advice is to build the cheapest computer possible(think ebay), including factoring in power requirements, attach a cheap but dependable hard drive. And while you're doing that, get advice on the Net on the best Linux distro for the task.

Hell, you might not even need actual database software, you could probably learn to implement about 10-15 Linux commands, and then mix and match them to do what you need.

[QUOTE=jasong;117056]No experience with databases, but my advice is to build the cheapest computer possible(think ebay), including factoring in power requirements, attach a cheap but dependable hard drive. And while you're doing that, get advice on the Net on the best Linux distro for the task.

Hell, you might not even need actual database software, you could probably learn to implement about 10-15 Linux commands, and then mix and match them to do what you need.[/QUOTE]

It is recommended that you don't speak on something you know absolutely nothing about.

I like MySql as well. However, converting all the stored procedures from MS SQL can be a tedious task if there are very many.

[QUOTE=rogue;117062]It is recommended that you don't speak on something you know absolutely nothing about.[/QUOTE]
Are you saying I'm wrong? At the very least, my advice is a possible avenue to consider. And it's not like I know NOTHING about databases. When you go to the grocery store, or look up a book at the library, or use Google, it's like a database. You use different algorithmic rules for each, but it's basically the same idea. You search for or insert data, you rearrange data, you reorganize data. Linux is fabulous at that. Heck, a BASIC program based on the BASIC programming language from the 1980s could probably do it, just very, VERY slowly.

The data is organized in a specific way, so one needs to come up with ways that take advantage of that. The only way there would be a problem is if each data point were written in a different way. But that would be a data entry problem, rather than a database problem.

[QUOTE=jasong;117091]Are you saying I'm wrong? At the very least, my advice is a possible avenue to consider. And it's not like I know NOTHING about databases. When you go to the grocery store, or look up a book at the library, or use Google, it's like a database. You use different algorithmic rules for each, but it's basically the same idea. You search for or insert data, you rearrange data, you reorganize data. Linux is fabulous at that.[/QUOTE]

For starters, take a look at [URL="http://en.wikipedia.org/wiki/ACID"]this[/URL] to see what a reliable database must offer. A database is a lot more that a glorified filesystem :wink: