MSSQL 2005 Finally Released 318
mnovotny writes "Computerworld reports that Microsoft is finally set to release their belated SQL Server 2005. From the article: 'Despite a two-year delay, several users who have tested the software cited the improved performance and new functionality it brings as positive developments that likely will convince them to upgrade soon.' The free version can be downloaded directly from Microsoft."
Re:Here's hoping (Score:4, Interesting)
Any ideas on UK availability? (Score:3, Interesting)
So what gives. The product is apparently out.. we want to buy it.. Microsoft have set the prices out.. so can we buy it or what?!
The favourable (p)reviews for SQL 2005 seem to be in stark contrast to those for Visual Studio 2005.. bloated, resource hungry, and bug laden.. apparently.
Re:Before you release the hounds (Score:3, Interesting)
Yeah? Lucky you! I certainly have.
If you're not using an MS language, you're going to probably be connecting to it using ODBC, which is slow and often buggy.
Also, my pet peeve about it is lack of a date type (as opposed to a DateTime type). This is part of the standard, so it should be in there. Its a pain to have to constantly cast your datetime into a date every single time you use it.
Re:Before you release the hounds (Score:1, Interesting)
Open Source, People (Score:2, Interesting)
Re:Free 'Express' editions released (Score:2, Interesting)
Not being a database admin, I can't comment on the advantages of MSSQL over other SQL servers, but I've heard people say that MSSQL is very resistant to data corruption caused by external factors (I guess they mean, hardware failure or filesystem corruption or the like). Can anybody confirm this?
Re:Free 'Express' editions released (Score:4, Interesting)
Yes, if by "free" you mean "free to use for one year [microsoft.com]":
That "for the term of that license" sounds like a loophole to me. Anyone seen the licenses that these "free" versions come with? Do they have a time period written into them?
meh! Meh! MEH! (Score:3, Interesting)
What problem are they trying to solve...I'll tell you what. SQL works well and is defiened by a standards committe outside their control...why don't we all do everything in vb instead. I betcha one of the reasons it took so long to get out was they couldn't make it run anywhere as fast as 2000 without tons of tweaking.
Re:Sigh. Stored procs in C# (Score:3, Interesting)
Re:Sigh. Stored procs in C# (Score:3, Interesting)
"Stored procedures" written in C# should really be thought of in the same way as the extended procedures from SQL Server 2000. In otherwords, you probably will never use that feature, and if you do find that you need it you must really scrutinize why and the security implications of doing so. In most cases, you're better off with straight T-SQL procedures, and that hasn't changed for SQL Server 2005.
Personally, I haven't yet found a good reason to use C# stored procedures, but I'm also not using SQL Server 2005 yet. When my team migrates in the coming months, I might change my tune, but for now I'm more interested in other feature enhancements like try/catch error handling semantics and the snapshot isolation levels (allows for better concurrency without having to risk dirty reads by using (nolock) or setting a "read uncommitted" isolation level).
Do you have examples of procedures gone horribly wrong? Preferably not something completely obvious, like a proc that takes a varchar(8000) as input and just passes that to exec (completely stupid, negates all of the benefits of using stored procs). From my experience, you're better off using stored procedures than dynamic SQL in your code, so long as a few sanity check requirements are in place -- limit the amount of dynamic SQL in your procedures, prefer table variables over temp tables (to prevent recompilations), and general T-SQL best practices: limit your use of cursors and looping since SQL is a set-based language, keep your transactions as short as possible, avoid forcing index hints, count() on an indexed column or better yet * (allows the plan engine to pick the best column to count on), etc.
Depends on what you mean by "application logic". If you meant to say "business logic", then I must vehemently disagree -- business logic should live close to the data, in a reusable form so it need not be implemented in each app that wants to use the data. Ideally that means stored procedures. If you can't implement your business logic in T-SQL, then you need to re-think your logic requirements and your schema. If it still can't be done, then you can go ahead and start moving it into external libraries, but you should try your best to keep your logic as close to your data as possible.
Re:Open Source making waves... (Score:2, Interesting)
Re: "Not many good tools for PostGreSQL" (Score:2, Interesting)
Re:Before you release the hounds (Score:4, Interesting)
I mean out of the box for server 2000 pricing last time I checked with a source of mine(3 years ago)(just checked an old email) and had a quote for 16k a cpu. And street price from Microsoft at the time direct was 20k per cpu.
Hell, even the new 2005 is only 24k per proc from MS on their site, and I am sure Tech Data, or some other company could get them two you cheaper. Whoever you were dealing with was charging you double.
So either this is FUD or just a rip off vendor.
Our shop supports MS, Oracle, DB2, and postgres. And you can move freely between any of those from one to the other, no vendor lock in.
Vendor lock in is when you use specific functionality inherent to MSSQl(or db2, oracle, post) so that if you need to move from one to the other, that is the guy who built the databases fault, not the company that supplies it.
Puto
Re:Sigh. Stored procs in C# (Score:4, Interesting)
Also, like the man says, sometimes there's other types of apps connecting to your DB, maybe not all within your control. If you're responsible for the health of the data and the system, you may not be able to trust that every developer or system is playing nice.