Execute Script From C# Application Rather Than From QA

How would I go about telling SQL Server to execute a script from a C#
application? Would I simply use ADO.NET's SqlCommand object - and have the
command text be a string that is the script (i.e., read the text file
containing the script into a string and set a SqlCommand object's
CommandType to .Text and set the CommandText to the string read from the
text file)?
Here's the "big picture" FWIW:
I have a non trivial script that I've been executing via QA. Rather than
executing it via QA, I want to include it as part of a larger installation
routine that is incorporated into a C# application.
Thanks.Hi
If you script has go statements then it will fail. The safest way to execute
the scirpt would be to break it down into into separate statements and then
excute those individually.
John
"Jeffrey Todd" wrote:

> How would I go about telling SQL Server to execute a script from a C#
> application? Would I simply use ADO.NET's SqlCommand object - and have the
> command text be a string that is the script (i.e., read the text file
> containing the script into a string and set a SqlCommand object's
> CommandType to .Text and set the CommandText to the string read from the
> text file)?
> Here's the "big picture" FWIW:
> I have a non trivial script that I've been executing via QA. Rather than
> executing it via QA, I want to include it as part of a larger installation
> routine that is incorporated into a C# application.
> Thanks.
>
>|||It has no GO statements. It does a few SELECTS and then just over 100
INSERTS. So, would you suggest 100 separate EXECUTE statements - perhaps
wrapped in an ADO.NET transaction?
"John Bell" <jbellnewsposts@.h0tmail.com> wrote in message
news:468F9060-ADA5-4330-B4E9-E23DE4BF5C49@.microsoft.com...
> Hi
> If you script has go statements then it will fail. The safest way to
> execute
> the scirpt would be to break it down into into separate statements and
> then
> excute those individually.
> John
> "Jeffrey Todd" wrote:
>|||Hi
If the inserts are all the same, then you may want to look at bulk loading
(possibly XML) or using a parameterised query and just setting data values.
If the size of your current statements do not exceeed the batch size then yo
u
may be able to run it in one execution.
Having everything wrapped in a transaction would be useful if you are adding
or modifying existing data, and you need the capability of rolling back to
where you started.
Because the requirements for each release may vary you may find that you are
constantly spending time twing your installation program to copy with the
different issues each release brings.
John
"Jeffrey Todd" wrote:

> It has no GO statements. It does a few SELECTS and then just over 100
> INSERTS. So, would you suggest 100 separate EXECUTE statements - perhaps
> wrapped in an ADO.NET transaction?
>
>
>
> "John Bell" <jbellnewsposts@.h0tmail.com> wrote in message
> news:468F9060-ADA5-4330-B4E9-E23DE4BF5C49@.microsoft.com...
>
>