What would you say if a developer wanted to implement a sql2008 dev environment, but we were still forced to use a sql2000 test and sql2000 production environment?
Would there be anything wrong with using sql2008 on a dev server? Of course you'd need to know what functionality you couldn't use, so you didn't have problems migrating your work from the sql2008 servers to sql2000.
I'd strongly avoid developing on a different local version than the dev/qa/prod environments. Most of the time nothing will happen, but when it does it can take forever to track down the issue. Not only that, you may never be able to replicate it locally since you have a different environment.
Using Basic SQL features - you'll do OK.
I have no idea why you use this environment, but it is best to use as similar environment and DEV, QA and Production as possible, to avoid surprise when going on production.
I think that SQL 2000 uses OLEDB and SQL 2008 you can use ADO.NET provider, And there might be many more differences that you might bump into. so the best advise it NOT TO DO SO.
I don't see why you'd have a development environment using a newer version of SQL server if your staging and production environments aren't.
No matter what software will act different based on version, and there could be a bug that could come up by not keeping the same versions. I'd recommend using the same versions across your entire environment.
How about setting up a Virtual Machine (eg. under Virtual Server 2005 R2 SP1 w/Update) that has the SQL Server 2008 environment on it? This would ensure that you don't contaminate your SQL 2000 environments with it, while at the same time allowing you to try things out. You can either set this up as a VM on a separate machine, or simply add it as a VM on you own development machine.
I think best practice would be to keep all of your environments the same. I can see it being userful to try out new functionality on the new environment to determine if it would be benefical updating your test and live systems.
What is there to gain by using 2008 over 2000 if you know you have get it to work in 2000?
There are so many issues with doing this:
Performance could be totally different even with the exact same SQL
DTS packages are handled totally different
You could unknowingly use code that is incompatible with SQL2000. You would not know until you moved it to test or live and by this point you could have done a lot of wasted development around incompatible code.
etc etc etc...
There is absolutely no reason to use a different version for dev than your LIVE environment. It will just end up causing you grief and inconsistencies.
Related
I am working on an application in my free time and I want to use a SQL Server database. I have the .iso for SQL Server 2008 R2 Developer but I don't have an extra computer to dedicate as a server. I assumed I could use VMware Player for a virtual server but from what I've read it seems that I would need VMware vCenter or another paid version.
Is there a free option for creating a SQL Server database virtually? This will be extremely small scale (3 tables and just for my personal use) so I am not worried about performance at all.
You can install that locally on your computer. There is no need for a virtual engine. Even if some of the MS documents say you need a server operating system, that is not the case. The setup has a check for valid operating system, and it just installs fine on Windows XP, Vista, 7 in my experience.
But if you want, VMWare Player would also work. In contrast to its name, you can also create virtual engines with it - but with some limitations.
And for a really small solution, even SQL Server Express, which is also free, would do. If I remeber correctly, the main restriction is that the data may not exceed 1 TB.
SQL Server can run locally without any problems, even in your dev/gaming/browsing computer without creating too much interference. There is no problem in installing it for testing and even for production of small systems (the express edition is free and valid for those uses).
Another, even slimmer, alternative, if you dare to upgrade to SQL 2012, would be to use a new feature called LocalDB. It's basically the very same db engine with a very important difference: it does NOT run as a service, but instead it's a regular program that is automatically started when a connection is attempted. Advantages would be that it does not consume resources until it's needed and yet you've got almost the full feature set of the real server. Here is an introduction on it. While I've never used it (always with the full express version), it seems good for the kind of programs you want to develop.
I'm currently working a contract for a company which will be moving an access database to MS SQL server in the future, and I'd like to hone my skills before the company makes the switch.
I'm also looking forward to possibly developing a rudimentary website which would have a simple HTML/CSS/JS front end, and those skills could also use a sharpening. I'd like to develop my skills through some SQL work locally on my home computer. Researching how to do that has only yielded the suggestion of installing an Apache web server with PHP and MySQL on my local machine. While I'm not opposed to doing that, the last time I worked with an Apache install, it was over-complicated and bloated.
Is there a more streamlined option? It doesn't seem necessary to load an entire web server for the specific use I'm going for.
I'd prefer to simply install a program that allows me to host the [My]SQL database locally, and perhaps later some way to test HTML and Javascript interacting with the database. I'm already somewhat familiar with Sequel Pro. As an added bonus, my Python skills are rusty and I'd like to get used to scripting Python. At this point Xcode (4.2) seems the likely solution here, but I'm open to other options.
I would be installing on a 11" MacBook Air running Lion and Xcode 4.2.
Apache and PHP ship with Mac OS X 10.7. MySQL installation is pretty straightforward with the package available from MySQL.
Take a look at these instructions--for your purposes, you can stop after the php.ini section.
Obviously a very subjective question.
I find CherryPy (with Python) for the web server and server programming, combined with jQuery to augment the HTML in the browser to be a powerful and lightweight combination. When possible, I use SQLite for the database — another extremely lightweight option. I share your distaste for Apache, at least when it's not needed.
If you want to develop solid skills that are peculiar to MS SQL Server, you really don't have much alternative to installing SQL Server someplace you can access it. Although you can certainly limit your use of SQL Server to standard SQL set-based commands SQL Server is more often used with a heavy emphasis on procedural code built into stored procedures. Those skills (writing SQL Server specific stored procedures) are only very minimally transferable to or from other database products.
If you were running Windows, you could get MS SQL Server Express for free:
http://www.microsoft.com/sqlserver/en/us/editions/express.aspx
In the end I just installed MySQL. I ended up following the instructions available from this blog post about setting up django, but not installing phpMyAdmin...
This post also has some good things about setting up passwords and such, since I really didn't want to be stuck relying on something else to admin the MySQL setup.
Are there any drawbacks to such a configuration?
These two databases are totally separate entities and you should have no problems running both of them on the same machine.
Short story: I wanted to test Hibernate with various database dialects, so I ended up installing these databases on one machine:
MS SQL server
MySQL
PostgreSQL
Oracle
DB2
and I had no problems with all of them running at once. Yes, it was a test server and the poor thing was totally running out of memory, but everything did work.
Only imaginable problem you could run into: configuring the same port for multiple databases. But you wouldn't do that, so it's not a problem.
Aside from the resources they would both consume (memory, disk, cpu); barring any purposeful conflicting configuration (by default they will listen on different ports), it would work fine.
No as far as I know.. I use both MS SQL and MySQL for my websites in the same box and no issues so far (2 years now!)
I have never run into an issue; they really don't step on each others' configurations at all.
If we have 3 developers working on the same Biztalk project what is the best way to set up our development environment?
We are using TFS to store the Biztalk project.
Should we use 1 sql server and 1 Biztalk server and then have 1 or more developer machines that access the sql and biztalk servers? The issue we get with this is when 1 developer compiles and deploys their changes it can effect other developers if they are also trying to compile and deploy their work.
Should we have each developer host their own complete sql and biztalk server for local development either on their machine or within their own virtual machine? The problem we find with this is that each developer could modify their server settings and those settings are not stored in source control. This can cause confusion when changes are deployed to a testing server. Another smaller issue is that each developer would need to have sql server, biztalk server and windows server installed.
Is there another way to set up a multiple developer biztalk development environment?
You will always want to have each developer have a complete BizTalk installation on their own machines. Believe me, it doesn't work otherwise, as you'll just keep getting on each other while trying to deploy/test/debug changes.
That said, you will also want a centralized dev/test environment where you deploy your code for more complete integrated testing and making sure all the changes from everyone are seen together.
Your point about configuration is true, but only up to a point. This is because you should make your solution configuration part of your source code and keep it in source control as well. This is particularly important once you're a bit ahead in your development as you'll need to start maintaining multiple versions of your binding files for each environment (dev, test, production and so on).
tomasr is right. Also, if you have decent hardware and lots of RAM, you may want to setup a VM image of your full developer environment, then share this will all your team. Not as fast as native hardware, but does allow you to roll back changes, replace your VM if you really mess up and everyone then has the same environment – ideally close to the target one.
Setting up a continuous build server is also a most, if your projects are small, you can get each checkin to cause a full build, BizTalk deploy, export of MSI and then run tests. Later as your solutions get more numerous you might have to move to a continuous build of C# changes only, then say nightly or several times a day, you do a full. We have done this with CruiseControl.net, Nant, nunit and various power shell scripts, it was pretty time consuming, but each morning we come to work to find a fully compiled, deployed, exported and tested set of BizTalk solutions ready for the test team.
I'm setting up a new development server and want to install the latest version of SQL Server 2008 Express.
Will our existing sql2005 databases work with 2008 without modification?
If so is there any reason to install both versions on the same server?
I haven't actually tried migrating a 2005 database to 2008, but generally SQL handles this cleanly and without difficulty. The simplest way to do it would be to make a backup of your database from SQL 2005 and then restore that backup with SQL 2008.
If you want to keep the SQL 2005 copy around and online until you know that the 2008 copy is working, you might need to move the data/log files for your database when restoring the backup onto 2008, since the old data files will be in use by 2005. You can do this using the with move option of restore database, for example:
RESTORE DATABASE mydb FROM disk = 'c:\backupfile.bak'
WITH MOVE 'maindatafile' to 'c:\newdatalocation.mdf',
MOVE 'mainlogfile' to 'c:\newloglocation.ldf'
As to having both installed at the same time, one reason you might decide to do this would be to simplify the job of testing code against both versions, if you were intending to have your software support talking to both versions.
You can detatch a 2005 database and attach it to a 2008 server. I would recommend against installing both on the same machine unless you must (e.g. you're writing code for a third party and they only use 2005).
What I'd highly recommend is using windows server 2008 hyper-v to create 2 virtual machines one with the 2005 environment, the other with 2008. Hyper-v virtual machines are incredibly faster than Virtual server 2007.
The databases should (should!) work unmodified. However, for development it is preferable that you have sql2005 to test your scripts unless you assume all your clients would upgrade to 2008 as well, since 2008 has features that do not exist in SQL Server 2005.
In dev and test environments, having multiple database servers installed is not a problem and can reduce the number of test servers required.
In production, I wouldn't recommend it due to the fact that multiple buffer pools fight and kill your performance.
To me the important thing is will you have prod instances that are 2005 databases? Will you have to support reporting services reports that are on a prod server that only has the 2005 version of reporting servives, etc?
If so, you should have both the 2005 and the 2008 versions on your development machines. I've seen a lot of code that had to be thrown out because developers worked on 2008 when prod was 2005. ALways develop against the version of the software you will have in prod. If you are converting to 2008 but not there in prod yet, you need both, one for maintenance changes and one for future stuff.
Personally I have SQL server 2000, 2005 and 2008 on my machine because we haven't converted everything yet and I have some things which can only be done on the older version. We have found the key to maintaining multiple versions is to install them i nthe correct order. It seems to go badly if you put 2008 on first and then the older versions.
Sometimes you need to be able to test on multiple versions, or you may need 2005 for one thing and 2008 for another.
Sometimes you maintain several different apps, some of which are on one and some on the other, and you haven't updated everything yet. Sometimes you're upgrading, and need to test on both versions during the upgrade. Sometimes you support several different customers, some on one version and some on another. Sometimes you want to upgrade your internal apps, but you're using a software package that is only certified on an older version.
There's lots of reasons.