Slashdot Mirror
MSSQL 2005 Finally Released
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."
Microsoft has a serious Beta Testing problem. Partially due to the fact there is little incentive for the Beta Testers to release the bugs, and Microsoft arrogance. Beta Testers should should be rewarded with their work with free copies of the final version, plus they shouldn't have to pay Microsoft for the honor of Beta Testing. Most of the Beta Testers I have seen are people who just want to learn the tool before it is released to the public so they get those jobs that are just popping up asking for people with 2 years of MS SQL 2005 experience.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I was under the (apparently mistaken) impression that this was already out.. our system admin called our software supplier today and the person on the other end of the line basically said that they have the prices for the product but Microsoft has told them not to actually divulge the pricing information until the end of the month! Excuse me??
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.
"Hey! Unless this is a nude love-in, get the hell off my property!!"
I never had any problems with SQL server
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.
Mod me down and I will become more powerful than you can possibly imagine!
Yes, actually I do.
I've used both SQL Server 2000 & MySQL 5.0.15 (and some others). Unless you want to make pretty pictures with DTS why wouldn't you decouple yourself from Bill Gates's teat and use MySQL 5? The major difference: limited support for triggers (which are generally a bad idea anyways as they hide code from lower-level developers).
i got ball this is my adress 108 20 37 av corona come n do it iam give u the sidekick so I can hit you wit it
As far as I know, the free MSSQL has a 2 GB database limitaton. That would be adequate for most developing purposes (I guess you are expected to buy the full fledged SQL for production).
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?
No sig
Yes, if by "free" you mean "free to use for one year":
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?
Read my blog.
great. Microsoft to deprecate t-sql for C# stored procedures. As a bonus they encourage you to not write orr understand SQL at all, well visual studio writes it for you. Well guess what, they want to obscure and redefine what a database is and what it is supposed to be. t-sql is a great language, queries are first class and it is designed from top to bottom to perform quickly and well.
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.
I'm well aware of the different layers. I'm also aware that a lot of times places need to have applications that they didn't write inhouse plug into the database. If the only things you are ever going to have interact with the database are apps you write in-house it's one thing. Not all of us are working in that situation.
"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.
I used up all my sick days, so I'm calling in dead.
Have you ever tried to use relational integrity with PostgreSQL and Erwin? Or is this new with PostgreSQL 8? Because it certainly doesn't work with PG 7.x and the latest Erwin SP.
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
Where were you pricing this? Some VAR that was trying to rape you?
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
The Revolution Will Not Be Televised
The persistence layer is nice for separating the logic in the app, but it doesn't mean you have to sacrifice the database server's built-in power & functionality. Persistence layers can map to stored procedures, views, etc.
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.
TODO: come up with a clever sig