I was wondering if anyone knew of any limitations to using Windows XP as a File and SQL server. I am asking because one of the applications we sell, requires the customer to setup a server for filesharing and as a SQL Server. We already allow them to use SQL Express, but we wanted to see if we can suggest Windows XP as a low cost alternative to Windows Server. The only potential problem that I could see if there were limits on the number of concurrent connections to either the files or the database. We are only thinking of recommending this for smaller sized companies who would have 10-15 users.
There is a limit of 10 inbound connections on XP professional, and 5 on XP Home. So it would only be practicable for a very small company.
From this MS KB Article:
Note For Windows XP Professional, the
maximum number of other computers that
are permitted to simultaneously
connect over the network is ten. This
limit includes all transports and
resource sharing protocols combined.
For Windows XP Home Edition, the
maximum number of other computers that
are permitted to simultaneously
connect over the network is five. This
limit is the number of simultaneous
sessions from other computers the
system is permitted to host. This
limit does not apply to the use of
administrative tools that attach from
a remote computer.
Per development: The connection limit
refers to the number of
redirector-based connections and is
enforced for any file, print, named
pipe, or mail slot session. The TCP
connection limit is not enforced, but
it may be bound by legal agreement to
not permit more than 10 clients.
I suggest reading the kb article for more information.
Actually, you can run SQL Server Standard or Workgroup Edition on Windows XP Pro. It is not limited to the express version ...
One cost effective alternative is Windows Small Business Server.
SBS 2003 R2: Features at a Glance
This will break the EULA.
Here is the relevant knowledge base article. Note that while TCP connection limits are not enforced for XP, legally they are limited to 10 connections.
Small business server seems like a better fit, and is cost effective if you shop around.
The problem with Small Business Server is all the frill it comes with that is unnecessary for a simple file and sql server; like exchange server, sharepoint, etc. I've used Windows XP as a small business SQL/File server, but as others have pointed out, you are limited to 10 connections legally speaking.
Another issue with Small Business Server is it can't be installed on an existing domain. Your best bet would be to package the SQL Server portion around a normal Windows server installation. If you're looking at 10-15 users, there's no guarantee that they have a domain. But if they don't, likely they are already dealing with the file server problem using accounts with same usernames/passwords on the file server(s) as on their individual workstations.
The number of connections is not related to SQL Server edition, but to the operating system. For example, Windows XP allows only 10 concurrent connections, Windows 7 20. For Windows Server OS [no need to purchase any new server machine ], the number of connections is unlimited (but you can limit is using Terminal Services).
The error message shown in case of connection limit reached is something like "the security limit reached...the number of concurrent connect attempts"
Presumably you are meaning SQL Express, as you can't run SQL Server on XP, it's a server product.
If the customer can afford your product, they can afford a copy of Server 2003, or whatever, the file sharing's built-in. Admittedly SQL Server's fairly expensive, but if your product needs it, that's the way it goes. If cost were an issue, you shouldn't be using SQL Server as the database platform. There's no point in trying to force a server-based solution into a client OS. You'll end up with all sorts of problems before long.
Doesn't the client have a domain-based infrastructure already?
The upshot being being if the client has 5-10 users of the software, they should be on SBS anyway for a variety of other reasons. You don't get SQL Server with it though.
(Samba would be an option for file-sharing, but doubtless more expensive than simply buying Server 2003 in this instance).
Related
I have developed a VBNET application that would require database connection (SQL Server 2005 Express) to a Windows Server 2000 PC. These applications will run in Windows XP and it is expected to be installed across at least 20 clients, all linked through LAN.
I would like to know if there are connection limits using Windows XPs or is the limit dependent on the server machine.
Also on a related note, are there limits for TCP/IP connections in the same case?
These are all so that I can decide whether to upgrade the client PCs to Windows 7.
Thanks in advance.
Yes, there are connection limits but there are a few things you need to consider:
The database-access paradigm in .NET is to pool and use database connections on an as needed basis. This way database connections are not held unnecessarily
From #1 above follows that a single database server should be able to service lots of clients simultaneously if you write your code correctly
20 clients is definitely within the realm of possibility - even for SQL Server Express which is not limited in terms of number client connections but is is limited by how much memory it can use and how many cores which indirectly limit the number of connections that it can handle. To the same point, there is a limit to how many TCP connections a Windows machine can handle but on a server OS the limitation will most likely come from resources (processing power and available memory) before you hit the arbitrary software limit of active TCP connections (which I believe is in the range of millions)
You are using seriously obsolete operating systems - these are no longer supported and you should move off of them as soon as possible!
The connection limits you're referring to only apply to incoming connections. For outgoing connections, you're fine. Additionally, the limits only apply to desktop operating systems like XP. Server 2000 does not have the same limitation.
In other words, this will work just fine... at least for a while.
However, the systems you're using are beyond obsolete... they are end of life. This means that no new patches are created or released for these systems, even when new critical vulnerabilities are discovered... and believe me, new vulnerabilities are discovered all the time. That makes these systems fundamentally insecure. It's irresponsible to continue using them, and only a matter of time until your network is hacked.
I suspect there should be no problem as those are separate pieces of software, but ideally I would like to have some 'official' confirmation or denial as it will be production environment.
I'm targeting newest versions of both databases.
I was not able to find any information in official channels, but maybe I was looking in the wrong places.
Information about individual successes of failures would also be useful.
The two products can co-exist peacefully because:
There is no overlap in the default installation path for the 2 products;
They don't require the same TCP port number for servicing requests - DB2 listens on port 50000 while SQL Server listens on port 1433.
Your real worries should be about server load during production.
Without knowing what your current usage is, the installation of another database server will at least impact resource contention and utilization (of CPU, memory, HDD etc).
Offcourse.
If you can't find anything against, that might be your answer.
We are in the process of rethinking our development environment. At the moment, we all have Elitebook notebooks which are not as fast as we'd like. We're thinking of virtualizing our development environment to a central VM server.
Our developers work in Visual Studio and use SQL Server as a database. We also have a few SharePoint developers who need a 64bit Win2k8 machine for SharePoint 2010. These are already virtual machines with their own local SQL Server installation.
Every developer's machine or VM has SQL Server installed. This requires resources from all boxes, and is challenging when working with a team on a project. Therefore we're looking into the possibility of centralizing the resources into a single DB server. That box would have to run multiple SQL Server instances (each Sharepoint developer needs a separate one to begin with). We also have the need for an older SQL Server 2005 and SQL Server 2000 installation for backwards compatibility. Besides the SQL Server box, the plan consists of a VM session for each developer with the development tools installed. So a developer could just RDP into the development environment, have his own image and make use of the centralized DB server. Test servers will also be virtualized in the same environment.
I'm looking for some tips and best practices on this matter. For instance:
What's the number of SQL Server instances a normal box can take? And if we upscale virtualized cores / memory; is that enough to add new instances? I don't expect heavy usage in dev.
What's the downside on centralizing the SQL Server instances as opposed to keeping a local instance on every development box?
How should this be integrated in a DTAP strategy?
Just some thoughts:
The number of instances is hardware dependent; I'm not sure if there's a mathematical formula to help calculate how many instances you can run on a VMbox, but it sounds like you're going to need a beast of a machine to run multiple instances per developer PLUS development tools (I can barely get SSMS and Visual Studio to play nice on my laptop). Better hardware = more cost.
Developing on a terminal system may have some advantages, but I can think of a few disadvantages as well:
network latency. If your developers work remotely at all, they'll
need a fast internet connection in order to do anything. If the dev
environments stay on their laptops, they could work disconnected.
instance interdependence. Although SQL Server instances are
completely seperate, sometimes you gotta reboot the server. You'll
need to coordinate that with all of your developers (may not be a big
deal if there's only a handful of you).
redundancy/maintenance. If one developer's machine is down, you
lose a person-day (is that even a word?) of productivity; if the
server goes down, your company is paying for a holiday for everyone
:)
Have you priced out what it would cost to upgrade your individual workstations so that you could compare costs on building out a centralized infrastructure?
Again, these are just some challenges that I think you should consider; there are probably ways to offset them, but they may factor in to your decision.
I would centralize the database servers as best as you can. Having all the dev's work off of centralized database instances should make migrating changes between environments MUCH easier. That alone is worth the effort.
For the SharePoint development environment, I'd highly recommend investing in a few books to make sure you go down the right path. You should be able to have all the dev's working off the same development instances for that too. Here is a good book on the subject, I'm sure there are others: SharePoint 2010 Development
As far as making the developer machines VM's too, I would seek the input of the development staff first and foremost and seriously consider Stuart's pros & cons.
I am upsizing an MS Access 2003 app to a SQL Server backend. On my dev machine, SQL Server is local, so the performance is quite good. I want to test the performance with a remote SQL Server so I can account for the effects of network latency when I am redesigning the app. I am expecting that some of the queries that seem fast now will run quite slowly once deployed to production.
How can I slow down (or simulate the speed of a remote) SQL Server without using a virtual machine, or relocating SQL to another computer? Is there some kind of proxy or Windows utility that would do this for me?
I have not used it myself, but here's another SO question:
Network tools that simulate slow network connection
In one of the comments SQL Server has been mentioned explicitly.
You may be operating under a misconception. MS-Access supports so-called "heterogeneous joins" (i.e. tables from a variety of back-ends may be included in the same query, e.g. combining data from Oracle and SQLServer and Access and an Excel spreadsheet). To support this feature, Access applies the WHERE clause filter at the client except in situations where there's a "pass-through" query against an intelligent back-end. In SQL Server, the filtering occurs in the engine running on the server, so SQL Server typically sends much smaller datasets to the client.
The answer to your question also depends on what you mean by "remote". If you pit Access and SQL Server against each other on the same network, SQL Server running on the server will consume only a small fraction of the bandwidth that Access does, if the Access MDB file resides on a file server. (Of course if the MDB resides on the local PC, no network bandwidth is consumed.) If you're comparing Access on a LAN versus SQL Server over broadband via the cloud, then you're comparing a nominal 100 mbit/sec pipe against DSL or cable bandwidth, i.e. against perhaps 20 mbit/sec nominal for high-speed cable, a fifth of the bandwidth at best, probably much less.
So you have to be more specific about what you're trying to compare.
Are you comparing Access clients on the local PC consuming an Access MDB residing on the file server against some other kind of client consuming data from a SQL Server residing on another server on the same network? Are you going to continue to use Access as the client? Will your queries be pass-through?
There is a software application for Windows that does that (simulates a low bandwidth, latency and losses if necessary). It not free though. The trial version has a 30-sec emulation limit. Here is the home page of that product: http://softperfect.com/products/connectionemulator/
#RedFilter: You should indicate which version of Access you are using. This document from 2006 shows that the story of what Access brings down to the client across the wire is more complicated than whether the query contains "Access-specific keywords".
http://msdn.microsoft.com/en-us/library/bb188204(SQL.90).aspx
But Access may be getting more and more sophisticated about using server resources with each newer version.
I'll stand by my simple advice: if you want to minimize bandwidth consumption, while still using Access as the GUI, pass-through queries do best, because then it is you, not Access, who will control the amount of data that comes down the wire.
I still think your initial question/approach is misguided: if your Access MDB file was located on the LAN in the first place (was it?) you don't need to simulate the effects of network latency. You need to sniff the SQL statements Access generates, rather than introducing some arbitrary and constant "network latency" factor. To compare an Access GUI using an MDB located on a LAN server against an upsized Access GUI going against a SQL Server back-end, you need to assess what data Access brings down across the wire to the client from the back-end server. Even "upsized" Access can be a hog at the bandwidth trough unless you use pass-through queries. But a properly written client for a SQL-Server back-end will always be far more parsimonious with network bandwidth than Access going against an MDB located on a LAN server, ceteris paribus.
I am running a server that needs a very limited number of user connections (max of 5 at a time). So the 5-CAL edition of SQL 2008 Workgroup seems perfect for me. Now, what I need to know is the following: do I actually need to physically install a CAL on each machine/user that will be using the server (by using I mean reading and writing) or does the 5-CAL licence simply mean that only 5 machines/users will be able to log at any one time?
I.e. can 6 or 7 different people use this as long as only 5 of them are connecting simultaneously?
Thanks
Karl
It's all here: SQL Server 2008 Licensing Frequently Asked Questions
However, it is not the easiest to follow.
Basically, a CAL is per user or device. The difference is under "What is the difference between device client access licenses (CALs) and user CALs?" is the link above".
Whatever CAL type you use, it does not matter if only 5 can connect at once. Or one client has 200 connections open.
It is per user or per PC (User CAL or Device CAL), not per connection. In the olden days (SQL 7?) you did have per connection but it has been some time since I looked at this.
Edit, to actually answer: they are not strictly enforced in that the SQL Server instance counts things, but you'll be using the software illegally.
It depends on what licensing model you go for:
Per CPU licensing - no CALs required, but you pay up front for unlimited user and device access. You are limited to the number of physical CPUs (not cores) you can have in the SQL Server box.
Per device CAL - you can assign a CAL to a physical device, and anyone accessing the SQL Server from that device is licensed. So 10 people accessing the SQL Server from 1 shared computer requires you to have 1 device CAL.
Per user CAL - you can assign a CAL to a person, and anyone accessing the SQL Server is required to have a license. So 10 people accessing the SQL Server from 1 shared computer requires you to have 10 user CALs, but 1 person accessing the SQL Server from 10 computers only requires you to have 1 CAL.
CALs are handled logically - there is no hard limit, just don't exceed the number of licenses you have.
http://www.microsoft.com/Sqlserver/2005/en/us/pricing-licensing-faq.aspx
http://www.microsoft.com/sqlserver/2008/en/us/licensing-faq.aspx