Max# free SQL Server databases / Server? 30 ok to avoid buying SQL Server?

If there's historical data in your database you can create a database to where you can purge old data.
Otherwise a single database by department should be the best solution to make you save money.

Thanks.  The old system was:  Canon Document Management.  We have about 300 gigs of data in it.  That system has reached end-of-life and Canon if migrating us to their current offering.

The scanned pages are supposed to be outside the database (in a ..\..\content sub-folder).  During the cut-over, it died after migrating only 30 gigs of data (20 gigs was indeed outside the database in the sub-folder, but for some crazy reason, the canon database in the sql instance had 10 gigs (the max) ).

We are having a conference call with Canon today so I wanted to ask about any pitfalls to their suggestion we have 30 instances of free sql server running.

@grendel777 raises a great point about memory requirements.  If they really mean separate SQL instances, then each will require memory and CPU resources.

The database that spaced out at 10 gigs was a catch-all canon database, it wasn't geared to departments so it really seems like they were suggesting separate sql instances.

Our environment is 4 VMware hosts, each with 4 procs.  

Canon's requires 4 procs minimum so we'd need to buy two 2-packs of SQL Server core licenses and buy Software Assurance (so we have rights to run it on a different host should one host fail).

The CAL model wasn't cost-effective since we have 60 users.

If we have to buy it, we'll have to buy it.  

We are furious that Canon who inspected our data and environment prior to the cut-over didn't foresee this issue.

They kept assuring us not to worry, they are the experts with an obnoxious "don't worry your pretty little head" attitude.

This cut-over has been a complete disaster.

Is it reasonable to be using SQL Express for 30 databases of 10 gigs each (300 gigs total)?

What if in 3 years we expect it to be 90 databases of 10 gigs each (900 gigs total): is that reasonable?

Thx
Mike

Thanks everyone.  I just got off the conference call with Canon.  They acknowledged their screw-up but implied it was really our fault because usually they do everything and in this case, we built the server and installed the product.

They didn't have a good excuse for seeing SQL Express and our existing system with 300 gigs of data and not saying anything.

Nonetheless, they suggested separate databases within one sql express instance as a work-around for our cheapness but then said that they ALWAYS recommend full blown SQL SERVER (not express).

They had no answer during the call as to why 20 gigs of imported data should result in 10 gigs of indexes and 20 gigs of scanned pages stored outside the database.  A canon engineer will remote in and try and figure out what is happening.

I asked them what the suggested max size for SQL express would be.  If we have 300 gigs in our old system does that mean we should expect 150 gigs in the database and 300 gigs of scanned images outside the database?

All in all, this is a complete #FAIL for canon.  Presently, we locked users out of the old system during the export and the new system is now offline since every cabinet was set to be in one database and that database is now full.

Anyway, thanks everyone!

Really the last thing I think I need to justify not using express is if the sum of all the data in the express database exceeds best practices.

Mike

Ironically, the minimum requirements for Canon's document management product is 4 cores.  

As pointed out above, SQL Express is limited to 1 core & 1 gig ram.

So, even suggesting express for such a database intensive application is just crazy.

We will go with SQL Full.

Thanks!

Mike

Thanks everyone!