Sql Server 2005 is broken

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Build
2. Try something with DBType
roundhouse.databases.sqlserver2005.SqlServerDatabase,
roundhouse.databases.sqlserver2005
3. See it crash

What is the expected output? What do you see instead?
See attached logfile

What version of the product are you using? On what operating system?
Latest version on Vista, connecting to a SqlServer 2005

Please provide any additional information below.
This happens because you distribute two versions of
Microsoft.SqlServer.ConnectionInfo in your project (One for 2005 and one
for 2008). In the build script, the second one will overwrite the first
one, rendering sqlserver 2005 support useless because it has a dependency
on the first version.

Original issue reported on code.google.com by lodewijk...@gmail.com on 17 Feb 2010 at 12:29

Attachments:

• msbuild.log

[GoogleCodeExporter]

Is there a reason why SMO is used and not the ADO.NET classes that are 
available in
the .Net Framework?

Original comment by jochen.j...@gmail.com on 17 Feb 2010 at 12:33

[GoogleCodeExporter]

I know we tried to use ADO.NET in the homegrown version (precursor to 
RoundhousE) 
and it did not work well for some reason.

I will say we use sql2005 at work without issue. You must have Sql2005 
installed on 
the box you run it from. 

Original comment by trueblu...@gmail.com on 17 Feb 2010 at 2:29

[GoogleCodeExporter]

You will need 2005 components in the GAC. The same goes for 2008 as well 
though.  I 
can't run 2005 from my home computer because I don't have SQL Server 2005 
installed.

Original comment by trueblu...@gmail.com on 17 Feb 2010 at 2:31

[GoogleCodeExporter]

Having 2005 installed on the box we run roundhouse from is not something we can 
to
require. I tried referrring to the 2008 assemblies in the project for 2005 and
everything seemed to work. The msdn page also seems to suggest that you can use 
the
2008 assmblies  to work with sql 2005
(http://msdn.microsoft.com/en-us/library/ms162557.aspx)

Original comment by lodewijk...@gmail.com on 17 Feb 2010 at 2:51

Attachments:

• [RoundhousE - Refer to 2008.patch](https://storage.googleapis.com/google-code-attachments/roundhouse/issue-19/comment-4/RoundhousE - Refer to 2008.patch)

[GoogleCodeExporter]

Yes, you can use 2008 assemblies to work with sql2005.

Original comment by trueblu...@gmail.com on 17 Feb 2010 at 2:57

[GoogleCodeExporter]

Here's the thing - 2005 is provided for those who don't have 2008 installed. If 
you 
have 2008, just use it. It will work with 2005 as well.

Someplaces, like where I work, do not have 2008 installed across the board yet. 
So 
they need to use 2005 and have it work with 2005 assemblies.

The sql2005 facility is provided so that people who do not have 2008 installed 
can 
use RH. Applying the patch you gave me would make it the same as 2008 and I 
could 
just get rid of 2005 and use 2008 instead.

Hopefully this makes sense - the different sql facilities are not about what 
database you are updating (provided it is still sql server). It's for what you 
have 
installed on your box.

So in short - if you have the 2008 assemblies, use slq2008 as your datatype. 
Not 
2005, even if you are updating a sql server 2005 database.

Original comment by trueblu...@gmail.com on 17 Feb 2010 at 3:19

• Changed state: Invalid

[GoogleCodeExporter]

Does all of that make sense? 
I really need to get some documentation out as to some of this. And a group 
where we 
can discuss these things. :D

Please feel free to hit me up at ferventcoder@gmail.com and I can send you my 
contact information so we can discuss this and other things you guys are 
seeing. 

Thanks for all the feedback. In the end I believe it will help make RH a better 
product.

Original comment by trueblu...@gmail.com on 17 Feb 2010 at 5:18

[GoogleCodeExporter]

It makes sense, but it also means you cannot run RH for SqlServer if the SMO is 
not
installed. This could pose a problem for us.

But we will try the pure ADO.NET way. The problem here is that GO isn't allowed 
in a
script that is executed by ADO.NET.
(http://weblogs.asp.net/jgalloway/archive/2006/11/07/Handling-_2200_GO_2200_-Sep
arators-in-SQL-Scripts-_2D00_-the-easy-way.aspx)

This means that the split for GO has to be adjusted again so to GO is removed 
from
the script. When we have tested this and it works we will provide a new patch.

Original comment by jochen.j...@gmail.com on 17 Feb 2010 at 8:30

[GoogleCodeExporter]

Why don't we do this? close this guy and add the SMO parts to Ado.NET to a new 
issue 
we can track separately.

Original comment by trueblu...@gmail.com on 17 Feb 2010 at 10:21

[GoogleCodeExporter]

Oh yeah - let's add this as well. 
Check the use of both types of comments in scripts.

/*
*/

--

I remember that was also partly responsible for SMO over ADO.NET.

Original comment by trueblu...@gmail.com on 17 Feb 2010 at 10:43