And who pays for the install time?

Are your customers happy to pay for your time to figure out this mess? And pay again and again for the time to install/re-install/fix/etc the tools you are using. And pay again because from experience I can guarentee you that deployment to a live server will be even worse than what you've been through already.

As a comparison - let's see how long it takes to install the world's best application development environment.

# apt-get install apache2 postgresql php5 pear smarty

# apt-get install apache2 postgresql php5 pear smarty

ooops - done it already!

So that was what? 16 seconds compared to a couple of weeks.

And you wonder why most of us developers are using the LAMP stack. And yes it does blobs and all the other gubbins.

Thanks loads though for confirming how bad this MS development stuff is. I had to use .NET for about 8 months and I nearly gave up programming due to it being so crap.

When will the penny drop for Winboys. You're shiny tools are ten years behind the curve. You can keep smashing your head into the GUI administration wall and running on the MSDN treadmill or step off and get yourself in a sports car.

"Storage in the database rapidly produced databases files that exceeded the 4GB limit on a 32-bit operating system"

Err what!?!

Under all the fluffy GUI shit is a very competent database. Very. I'm certain it's better than postgres, as I've seen what it can do.

That said, there is a whole load of shit on top to 'add value'. I suspect Mr. Whitehorn would have been better off starting from sql server 2000 and adding in his stuff.

I endorse the reaction of @Simon. What are you talking about re. 4gig limits? The limit on eg. MS windows 2000 is terabytes for files. For ram space you can go up to 64gig on old (32-bit) hardware with some tweaking, but you're using 64-bit aren't you so WTF?

And why worry about DB size? Overall size counts - total data doesn't get smaller if you store it outside the db; there's just as much to back up, only it's in pieces... which makes reliable backup during runs problematic, if a file is added/deleted while backup is going on.

Please explain!

Badly patched Sybase reissue grinding along on a reworked GUI shell for a CP/M rip-off.

Think you'll find VS is the most popular IDE used.

And I think you'll also find that the LAMP stack in question isn't beta - it's a full release. This is a CTP.

The day a LAMP developer spouts how easy it is to setup their environment compared to a .Net is the day I move to <shudders> Mac OS X </shudders>

Oh, and out of curiosity, your telling me that you can install a web server, database and IDE with a single command...? Not specifying default passwords, components, locations and tools? In a single command?

And a final point Mr. LAMP lover - you can install the .Net environments (DB, IDE, reporting suites, Framework etc.) all via command line as well. Just most people prefer ease of use when installing a new technology that's currently unreleased rather than obsecure commands. Saves on the admin overhead when your TESTING BETA SOFTWARE

Jerk.

@Jerk

Boy it must have been tough at school having a name like that!

VS most popular?

Probably not - just check out the number of jobs asking for PHP. And when has 'popular' equated to 'good'.

The install DOES work from a single command. Listen carefully because you may be close to enlightenment, grasshopper.

All packages install with sensible, secure defaults. All packages also install a README file which will explain clearly any further steps.

There - that's it. I've installed (L)AMP so many times I now even cut and paste the line from my notes.

What I suggest is find someone to show you. You'll be amazed how easy it is.

And being offensive is pretty small minded - but I suppose that explains why you can't learn anything.

@Jerk

Just to explain one of the many things you don't know.

You CAN install a DB without setting a password.

For the Postgresql DB an admin user called postgres is set up during install. It is secure by default as you can not log in as this user.

To become this user you type

su - postgres

and then carry out commands such as createdb and create(db)user.

See, simple, easy and yet something else about which you know nothing. You have to LEARN stuff.

Then to create a DB you type

createdb

or to create a user you type

createuser

OK, my bad.

The problem was my careless editing. This article was supposed to be 800 words long and my initial draft was over 1,200; so some serious surgery had to be performed. This section originally read as:

“As it happens, our application has a great number of BLOBs. In SQL Server 2005 we tried both approaches. Storage in the database rapidly produced databases files that exceeded the 4GB database file limit that was imposed because, just to get started, we were using SQL Server 2005 Express running on a 32 bit operating system. We did some further testing and tried storing the BLOBs in the file system. This was better but managing the pointers to ensure that the pointed to the correct BLOB - in our case by bar codes - was time consuming and limiting. So, when the CTP arrived we moved to 64 bit (as described in an earlier article) and started using the file streaming which has proved to be fabulous for our application.”

130 words – far too long. So I edited it down to this:

“As it happens, our application has a great number of BLOBs. In SQL Server 2005 we tried both approaches. Storage in the database rapidly produced databases files that exceeded the 4GB limit on a 32-bit operating system. Storing the BLOBs in the file system was better but managing the pointers to the correct BLOB - in our case by bar codes - was time consuming and limiting.

File streaming is fabulous for our application.”

Which is a much trimmer 74 words. Sadly I failed to notice that I had ended up implying that there is a 4 GByte limit on 32 bit OSs.

But, SQL Server Express has a 4GB limit? Wow. I'm not used to using software with artificial limits placed on it.

Thanks for explaining that. nonetheless you aren't half making a massive rod for your own back by beta testing for MS. Seriously, are you going to use the express version for your final deployment? If not, why are you having to deal with its limits? And why (oh why etc.) don't you take a stable DB (SQL server 2000/5 for example) and see if you can graft your geo stuff on top. There must be someone who sells these calculations in a library you can buy.

I hope you actually get something back from MS to repay you for all you're doing on their behalf. If they can't put together a decent beta install then they don't deserve beta testers at all.

Okay, here's a suggestion. Install 2000 or 2005, and 2008. Do all data storage etc on 2000/2005 and link to them via linked servers (whatever it's called) from 2008. The data looks local to '08; you just have to refer to the tables as

server.db.owner.table in your select statements. For flexibility you should define SPs or views to hide even this syntax.

*if* that works then you have the benefits of one with much less crap of the other, until MS ships a working '08.

I'm bored and I might be able to help. My email is <qqq.ppp2 (ta) gmail.cooom>, demunge the obvious.

@ bored AC

"Seriously, are you going to use the express version for your final deployment?"

"nonetheless you aren't half making a massive rod for your own back by beta testing for MS"

Thanks for the comments. No, we won’t be using the Express version – we were using that early on (in fact, in the 2005 version) to do some rough prototyping and it happened to illustrate rather elegantly that the database file size was getting quite large, even with relatively few blobs.

And no, I don’t think we are making rods for backs. The original decision to use the 2008 stack was made precisely so that we could gain experience with 2008. You will have gathered that the download/install of Microsoft CTPs does not fill me with awe and wonder (or, rather, it does, but only in a bad way….). However all of the rest of the CTP program, actually using the software has been, as reported in the rest of this series, remarkable pain free. We have gained huge experience and both the management and the developers are extremely happy that we decided to go down the CTP route.

Had we started with 2000/2005 as you suggest we wouldn’t have gained the experience.

@Kevin Bailey

Kevin asks an interesting question “Who pays for the install time?” The answer is the management. Are they happy to do so? They are delighted. Why? Because they understood at the time the decision was made that working with a CTP program has associated costs. They (not the developers) decided that the benefits were likely to outweigh the costs and, happily, in this case, they have been proved correct.

@AC (possibly the same one, possibly not, it’s difficult to tell…..)

“And why worry about DB size? Overall size counts - total data doesn't get smaller if you store it outside the db; there's just as much to back up, only it's in pieces... which makes reliable backup during runs problematic, if a file is added/deleted while backup is going on. Please explain!”

It’s always a trade off. Keeping the BLOBS in the file system can be an advantage if the blobs are mainly static and can be compartmentalised. That way you can only backup the new BLOBS and it makes the backup of the database much faster because it is smaller. However I don’t want to make it sound as if these were the only considerations. We could, for example, also have partitioned the database and achieved a similar (but not identical) effect. It is easy to see these architecture decisions as simple – in fact they are relatively complex and there was some discussion and testing before we made the decision. (Indeed, that is another reason why we wanted to use the CTP, so that we could do the testing!).

How do filesystem-BLOBs work? My last experience was/is with SQL Server 2000 and I didn't even know this option was available. Maybe because most of my BLOB experience comes from PostgreSQL, basically the lo_*() functions.

@Kevin - Wouldn't that be LAPP stack? "LAMP" implies MySQL *retch*

@ACs - Hm, you could install DB2 UDB on a Linux box, with all the added benefits of a graphical installation, and the db2 Command Center. See, using the Linux platform doesn't automatically restrict you to Postgres/mySQL ;)

All that said, SQL Server is a fairly decent DBMS, even if it is a blatant Sybase fork. Though I've been able to bring it down with a triple self-join without WHERE parameters ... watch the server go down! Weeeeeeeeeee!!!!!

Yep, same AC.

"That way you can only backup the new BLOBS and it makes the backup of the database much faster because it is smaller."

Or use a differential backup?

I dunno. you seem to have chosen the most rocky route up this mountain. I'll be watching your progress with interest.Best of luck.

what are you guys about? I mean really.

Just use the database to point to the binary file and go do somethig productive.

... I mean REALLY.

It's because of people like you I keep getting promoted.

* sigh *