April 29, 2008 at 5:43 am
I am currently undertaking to replace an Access system with SQL Sever 2005 and Crystal Reports as the company I work for has outgrown the existing set-up.
Whilst I have developed and managed a SQL installation I haven't had to purchase one before and would very much appreciate an experts confirmation (or correction!) before I take the plunge.
The company has around 27 users (which may expand slightly in the near future) not all of which will access the server at the same time who all work from separate machines (if this is relevant).
I have come to the conclusion that SQL Server Workgroup Edition with a processor license structure is the way to go with regards to cost and possible future expansion (the database does not hold a huge amount of data and all reports will be comfortably handled through Crystal).
Does this model seem reasonable or am I missing something? Are there any drwabacks of chosing Workgroup over Standard for this scale of application? Many thanks for your help.
April 29, 2008 at 7:25 am
You should look at the feature lists for the editions of SQL to make sure you do not need standard edition features.
Per-processor licensing seems a lot for you. Per-user licensing always seems to be cheaper up to about 50 users unless you happen to be using a single-processor server (can you even buy one of those these days?).
MS used to license by concurrent connections - they do not any more. Now it is by devices or per-processor. So, the easiest way to determine the best licensing model is to count the number of devices that will use applications that access the SQL server. If you have 25 desktop machines, 10 laptops, and 5 handhelds - you need 40 CALS or per-processor licensing.
Talk to your software rep - I am sure they can help you through the process.
April 29, 2008 at 7:39 am
Michael Earl (4/29/2008)
You should look at the feature lists for the editions of SQL to make sure you do not need standard edition features.Per-processor licensing seems a lot for you. Per-user licensing always seems to be cheaper up to about 50 users unless you happen to be using a single-processor server (can you even buy one of those these days?).
MS used to license by concurrent connections - they do not any more. Now it is by devices or per-processor. So, the easiest way to determine the best licensing model is to count the number of devices that will use applications that access the SQL server. If you have 25 desktop machines, 10 laptops, and 5 handhelds - you need 40 CALS or per-processor licensing.
Talk to your software rep - I am sure they can help you through the process.
I would tend to agree with Michael - per proc might be overkill for the number of people. That being said - you still might care to check whether it's cheaper to buy user CAL's or device CAL's. Remember - these are not "concurrent use" CAL's, so you'd have to add up all of the devices (a user's desktop, their laptop and their home PC connected in via VPN each count as one), count up the distinct users, run the numbers on both models and see what comes out better.
Now - keep in mind that this assumes you are using Crystal to serve only your internal network. If it's outward facing (meaning clients can access it, etc...) then your per processor model might make a lot more sense (it would likely becomes required if outwardly facing).
Here's where microsoft lays out "the rules" for each licensing model:
http://www.microsoft.com/sql/howtobuy/licensing.mspx
As to cost - you'll have to talk to a licensing specialist at whichever vendor you use for that kind of stuff.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
April 30, 2008 at 7:04 pm
Not really answering your question (seems like the previous post's did that), but i am curious what you will use for a UI now. Are you sticking with Access, or rewriting it all in some other language?
April 30, 2008 at 11:49 pm
Thanks for the replies, seems like I have a little more digging to do with my vendor 🙂
I'll be re-writing/re-designing the front-end in VB if that's a help.
May 2, 2008 at 8:57 am
I'll be re-writing/re-designing the front-end in VB if that's a help.
That's good. Access front ends to access an Access database works well, but VB is a much better front end for SQL Server that Access.
May 2, 2008 at 9:27 am
Not true in a general sense, as long as you don't have issues with user's not having Access licenses then Access can be better than VB (and other languages). Depends on the developers proficiency and user requirements. Access gets it's bad rap because of applications built by non-developers that overreach.
May 2, 2008 at 9:41 am
MS Access is like anything else. If you use it for what it is designed for, it works pretty well.
Jello is great as a snack, but an awful building material.
May 2, 2008 at 9:46 am
Not true in a general sense, as long as you don't have issues with user's not having Access licenses then Access can be better than VB (and other languages). Depends on the developers proficiency and user requirements. Access gets it's bad rap because of applications built by non-developers that overreach.
I stand by that comment. Although I haven't programmed in Access 2007, I used to program in both Access and VB, but my Access skills were superior to my VB skills. Unlike most IT people I work with I consider Access to be a superior product and enjoyed developing in it. But VB provides a much better interface with SQL Server, especially with it's use of class modules and ease of abilty to create an installation routine. If you don't know how to program in VB, that may not be the best time to learn, but all things being equal, I will always choose a VB front end over an Access front end when the back end is SQL Server.
May 2, 2008 at 11:50 am
If that is true, then why not a VB front end to an Access backend. If you program correctly the data store should be immaterial.
May 2, 2008 at 12:10 pm
C'mon. I've seen VB front ends with Access back ends, and they work, but we're talking about what works best, not what just works. With an Access backend, there is nothing so good as an Access front end. But with a SQL back end that changes. I've worked with all four combinations. The only concession I would give is that I haven't worked with Access 2007, and they may have made access work better with SQL Server with the .adp files. I haven't had a chance to try that since we don't need that at my company anyway.
May 2, 2008 at 12:30 pm
Give some specifics. Why do they work better? I'm not trying to harass you, but I have had many discussions like this over the years and haven't heard very many arguments that stand up. For the record, I have built front ends using VB (classic), VB.net, and Access, and each has it's strengths and weaknesses. Tell me what you believe to be a specific weakness of using VB (any flavor) to connect to Access, outside of the obvious size limit on Access, which isn't a weakness of VB, just a limit on Access.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply