I do network support for a web development firm who wants to setup a machine or machines to do MS SQL Server development on. The lead SQL programmer basically wants each programmer to have a box running W2K server and SQL Server 7 to use as their workstation. Cost aside, (a pretty BIG aside), using a server platform as a workstation just doesn't seem right to me. Is this the way that all of you are doing it? She (the programmer) swears that this is the way it's done.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Best Practice or Suggestions for Development Platform?
- Thread starter ScottSN
- Start date
Hi,
You don't need a server to run sql server on. Generally the datbase will be stored on a server and client side sql will be loaded onto the workstations allowing all developers to access the one database. On the other hand if each developer requires an induvidual database I have an sql 2000 database running quite happily on a 2 year old desktop
You don't need a server to run sql server on. Generally the datbase will be stored on a server and client side sql will be loaded onto the workstations allowing all developers to access the one database. On the other hand if each developer requires an induvidual database I have an sql 2000 database running quite happily on a 2 year old desktop
If you install the client tools on the desk top you will have an Enterprise Manager MMC (with snap-ins installed) and can then register your SQL Server(s) and work with that.
T-SQL is just text so you can write code with anything, but the MMC gives lots of cool tools. If you already know that stuff please accept my apology. JHall
T-SQL is just text so you can write code with anything, but the MMC gives lots of cool tools. If you already know that stuff please accept my apology. JHall
- Thread starter
- #5
Thank you all for your responses. JHall, I am a hardware/network/OS guy, not a programmer, so all this stuff is new info for me. The programmer who wants to work off the server said her reason was that she could build and manipulate the structures directly, and then simply copy it up the the (virtual) host for the website. MSDE, MDAC, T-SQL, are a little confusing for me. While I know that some of the tools allow you to develop on a desktop that doesen't have to be connected to a SQL server, I don't know what you may lose in functionality or ease of use. The same goes for Developer's Ed. running on W2K Pro.
If you, (meaning anyone out there!), needed to setup an environment for 2 or more SQL programmers to develop DB's for websites, how would you do it, (products and versions)? For example, 2 W2K Pro workstations running SQL Server Dev. Ed., or 2 workstaions running client attached to a dev. server running W2K server and SQL server standard?, etc.
If you, (meaning anyone out there!), needed to setup an environment for 2 or more SQL programmers to develop DB's for websites, how would you do it, (products and versions)? For example, 2 W2K Pro workstations running SQL Server Dev. Ed., or 2 workstaions running client attached to a dev. server running W2K server and SQL server standard?, etc.
I think the development staff is headed for trouble with this technique (allowing any developer to manipulate the database structure). A better way would be to appoint one person as DBA, give that person full control of the shared database, and everyone else has to make requests to them for their needed changes.
This way you only need two full copies of SQL Server for the development group -- one on the DBA's desktop for him/her to try things out on, and one for the shared development SQL server for everyone else to share as they write code.
There's cost savings in the operating system expenses, too. The developers don't need Win2k Server, all they need is Win2k Pro. If they need to upload components to a COM+ server, they can use Terminal Services (you get two free licenses with each copy of Server).
Chip H.
This way you only need two full copies of SQL Server for the development group -- one on the DBA's desktop for him/her to try things out on, and one for the shared development SQL server for everyone else to share as they write code.
There's cost savings in the operating system expenses, too. The developers don't need Win2k Server, all they need is Win2k Pro. If they need to upload components to a COM+ server, they can use Terminal Services (you get two free licenses with each copy of Server).
Chip H.
- Thread starter
- #7
Chip, thanks for responding. I'm really fuzzy about this whole matter. Not being a programmer, there's a lot of areas that are probably "self-evident" to experienced SQL folks, but are unknown to me.
I'm sorry to be so "clueless" on this subject.
If I understand you correctly, you are saying that I should use 2 full copies of SQL standard, not developer edtion. The DBA's workstation would be running Win2k Server, (necessary to run SQL Server Standard?), with full SQL server standard installed. The other developers would use Win2k pro as their OS and run the standard SQL client to program on(?).
The 2 free terminal services sessions that come with Win2k server run "administrative" terminal server sessions. They are supposed to be "subtle" differences between the administrative TS and the "Application Server Mode" TS sessioins, because the 2 free sessions are intended to do server admin rather than run apps., according to MS. Have you had success using SQL through the admin (free) TS sessions?
Again, THANKS to everyone who responded, and hopefully will continue to respond! I'm still pretty confused, but I have more info now and have noticed that there seems to be a number of ways to set it up,(makes me feel better about being confused).
I'm sorry to be so "clueless" on this subject.
If I understand you correctly, you are saying that I should use 2 full copies of SQL standard, not developer edtion. The DBA's workstation would be running Win2k Server, (necessary to run SQL Server Standard?), with full SQL server standard installed. The other developers would use Win2k pro as their OS and run the standard SQL client to program on(?).
The 2 free terminal services sessions that come with Win2k server run "administrative" terminal server sessions. They are supposed to be "subtle" differences between the administrative TS and the "Application Server Mode" TS sessioins, because the 2 free sessions are intended to do server admin rather than run apps., according to MS. Have you had success using SQL through the admin (free) TS sessions?
Again, THANKS to everyone who responded, and hopefully will continue to respond! I'm still pretty confused, but I have more info now and have noticed that there seems to be a number of ways to set it up,(makes me feel better about being confused).
The DBA's workstation would be running Win2k Server, (necessary to run SQL Server Standard?), with full SQL server standard installed.
Yes. I know there isn't supposed to be any difference between SQL Standard and SQL Desktop, but running the real thing would eliminate the chances of any finger-pointing later ("Well, it works on my machine!"
.
We use the terminal services clients for administrative purposes too -- when you're installing new COM+ components, you have to copy them to the server (simple network file access), but you have to register them through the Component Services console, which requires you either walk over to the box (annoying), or use terminal services to run it from your desktop. This isn't related to SQL Server directly, but more of a general practice. You can do almost everything you need via Enterprise Manager and Query Manager, anyway.
A big part of development management is configuration control. A couple of companies ago I worked with a fellow who got ahold of the MSDN Universal CDs. He proceeded to install everything that looked interesting to him. When his code check-ins failed to compile, he said "Well, you guys just need to upgrade!". I about killed him, as we were targeting a certain configuration on the user's machine, and he just blew it out of the water. We lost 1-2 weeks on his "upgrades".
Speaking of source code control: if you're using Visual Source Safe for version control, part of your time will be spent fixing corruption issues in it (our engineer spends about a 4 hours a week on it alone). I wish I could recommend a better product, but all the alternatives (PVCS (and variants), Perforce, Code Co-Op, Continuus (now Telelogic CM)) are either too expensive, or clunky to use. For now, VSS is the best available (until something better comes along).
Chip H.
Yes. I know there isn't supposed to be any difference between SQL Standard and SQL Desktop, but running the real thing would eliminate the chances of any finger-pointing later ("Well, it works on my machine!"
.We use the terminal services clients for administrative purposes too -- when you're installing new COM+ components, you have to copy them to the server (simple network file access), but you have to register them through the Component Services console, which requires you either walk over to the box (annoying), or use terminal services to run it from your desktop. This isn't related to SQL Server directly, but more of a general practice. You can do almost everything you need via Enterprise Manager and Query Manager, anyway.
A big part of development management is configuration control. A couple of companies ago I worked with a fellow who got ahold of the MSDN Universal CDs. He proceeded to install everything that looked interesting to him. When his code check-ins failed to compile, he said "Well, you guys just need to upgrade!". I about killed him, as we were targeting a certain configuration on the user's machine, and he just blew it out of the water. We lost 1-2 weeks on his "upgrades".
Speaking of source code control: if you're using Visual Source Safe for version control, part of your time will be spent fixing corruption issues in it (our engineer spends about a 4 hours a week on it alone). I wish I could recommend a better product, but all the alternatives (PVCS (and variants), Perforce, Code Co-Op, Continuus (now Telelogic CM)) are either too expensive, or clunky to use. For now, VSS is the best available (until something better comes along).
Chip H.
- Thread starter
- #9
I guess that it isn't so strange to use a SQL Server as a workstation directly.
I take it that SQL Desktop is what you run when you are using Developers Edition(?) Is that the same as MSDE? Although I've read a fair amount about MSDE and MDAC, it is still kinda nebulous to me.
It's probably one of those concepts that is extremely simple... if you are already familiar with it.
There are many things, (SMTP vs. POP, the Registry, VPN's, Firewalls, etc.), that seemed difficult to understand before I became familiar with a few key concepts. Until then, you couldn't put the pieces together because you didn't have a framework to place them in. Once a couple of things fall into place, all the rest follow.
Thanks for taking the time to respond. I know my comments may sound like I "don't get it", but I'm trying.
Although I won't be involved with the control of the source code, or any development management, I will probably be called upon if something gets roached. Thankfully, there are only 2 programmers (at present). Theoretically, they could both work off the server through the Term. Svcs. clients!
I take it that SQL Desktop is what you run when you are using Developers Edition(?) Is that the same as MSDE? Although I've read a fair amount about MSDE and MDAC, it is still kinda nebulous to me.
It's probably one of those concepts that is extremely simple... if you are already familiar with it.
There are many things, (SMTP vs. POP, the Registry, VPN's, Firewalls, etc.), that seemed difficult to understand before I became familiar with a few key concepts. Until then, you couldn't put the pieces together because you didn't have a framework to place them in. Once a couple of things fall into place, all the rest follow.
Thanks for taking the time to respond. I know my comments may sound like I "don't get it", but I'm trying.
Although I won't be involved with the control of the source code, or any development management, I will probably be called upon if something gets roached. Thankfully, there are only 2 programmers (at present). Theoretically, they could both work off the server through the Term. Svcs. clients!
Yes, MSDE, SQL Desktop Edition, etc. are all referring to the same thing. It's supposed to be the same as the full-strength versions, only limited to 5 connections and 2gb worth of data. I'm sure there are other limitations, which is why I recommended the DBA be running Windows Server and SQL Server (full copy), just to make sure it doesn't cause any problems later.
The hardest thing I find about dealing with Microsoft is when they rename a product. I've known MTS for years, but now it's COM+, and in .NET it's going to be called "Enterprise Services". It's like when Access went from 1.1a to v3.0 without going through a version 2 -- drove me nuts!
Good luck in your new job, be sure to ask again if you have any questions.
Chip H.
The hardest thing I find about dealing with Microsoft is when they rename a product. I've known MTS for years, but now it's COM+, and in .NET it's going to be called "Enterprise Services". It's like when Access went from 1.1a to v3.0 without going through a version 2 -- drove me nuts!
Good luck in your new job, be sure to ask again if you have any questions.
Chip H.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question