conditionally executing sql statement

I need to write .sql file in a dynamic way.
inside the file i need to decide at run time (of the sql script) whether or
not to run a SQL statement that I don't know it's content while dynamically
creating the sql script, this sql statement might include a GO statement
what makes a problem putting it inside an if begin end block.
for example
in my script a runtime check
select @.runStatement = configVal from database at script runtime execution
if @.runStatement =1
begin
-- here comes an unknown sql statement at the time of creating the sql
script that might include a GO command which will break the syntax of the
entire block
-- go <- this here makes a TSQL error for the end command since it
breaks the begin / end block.
end
can someone recomend of an approach for how to solve this?
execute sql is not an option here since the internal SQL statement might be
larget then 4000 nvarchar characters and I can not declarae a @.ntext local
variable
TIA.>> inside the file i need to decide at run time (of the sql script) whether
Under normal circumstances, this is a poor way to write SQL code. The kludgy
workaround is to assign the SQL statement to a variable, replace the tokens
that are not needed and use EXEC or sp_ExecuteSQL to execute it.
The right way can be suggested only if you can explain the overall
situation. Why do you have to resort to such complex approach? Is there a
3rd party tool involved?
Anith|||martin (news.microsoft.com) writes:
> I need to write .sql file in a dynamic way.
> inside the file i need to decide at run time (of the sql script) whether
> or not to run a SQL statement that I don't know it's content while
> dynamically creating the sql script, this sql statement might include a
> GO statement what makes a problem putting it inside an if begin end
> block.
> for example
> in my script a runtime check
> select @.runStatement = configVal from database at script runtime execution
> if @.runStatement =1
> begin
> -- here comes an unknown sql statement at the time of creating the
> sql script that might include a GO command which will break the syntax
> of the entire block
> -- go <- this here makes a TSQL error for the end command since it
> breaks the begin / end block.
> end
>
> can someone recomend of an approach for how to solve this?
> execute sql is not an option here since the internal SQL statement might
> be larget then 4000 nvarchar characters and I can not declarae a @.ntext
> local variable
Are you on SQL 2000 or SQL 2005?
If you are on SQL 2000, I would srtongly recommend that you run the
control loop from a client. It could be very difficult to sort out
from SQL only. It could be a little easier on SQL 2005, since there
you can work with nvarchar(MAX) and you could do the batch splitting
in CLR code.
I echoes Aniths suggestion that you could be better served by telling
us the full story. This could give you better suggestions.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||it should support database modifications / upgrades.
the commands are not known at the time of designing the tool that will
execute the statements.
i understand that running each script from a client tool like a VB.NET app
is a good option but is it not possible to run it from sql script file using
some goto label....?
"Anith Sen" <anith@.bizdatasolutions.com> wrote in message
news:eedlU0VaGHA.1020@.TK2MSFTNGP02.phx.gbl...
> Under normal circumstances, this is a poor way to write SQL code. The
> kludgy workaround is to assign the SQL statement to a variable, replace
> the tokens that are not needed and use EXEC or sp_ExecuteSQL to execute
> it.
>
> The right way can be suggested only if you can explain the overall
> situation. Why do you have to resort to such complex approach? Is there a
> 3rd party tool involved?
> --
> Anith
>|||martin (news.microsoft.com) writes:
> it should support database modifications / upgrades.
> the commands are not known at the time of designing the tool that will
> execute the statements.
> i understand that running each script from a client tool like a VB.NET
> app is a good option but is it not possible to run it from sql script
> file using some goto label....?
Possible and possible. With severe kludges maybe. And it depends on the SQL
Server version.
If the purpose of the tool is run scripts for database changes, I strongly
recommend using a control part in a client language.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspxsqlsql

concurrency and timestamp or datetime

Hi everyone!

I've read a lot of document about optimistic concurrency and different implementations which made me decide to chose the timestamp/datetime approuch to validate if another user has editet the record.

I'm saying timestamp OR datetime because I dont really care which one to use but I can't make any of them work as expected.

Here is my setup:

I'm using a DataSet (autogenerated by Visual Studio 2005) with 4 stored procedures to select, update, delete and insert records.
I'm using a GridView to show these values but when using a timestamp in the database the parameter type in my ObjectDataSource is an Object which ofcause ins't right and I can't change it to Byte[].
If I instead use a Datetime I believe that the date formatting is done somehow (even though i make the field ReadOnly in the GridView) - I can see the date is shown as:"01-01-1900 00:01:07" but the actually SQL that is executed is: 'Jan 1 1900 12:01:07:000AM' why this differense?

So my question is which one should I use and how - the datetime/timestamp dosn't have to be shown - I would actually prefer that the datetime/timestamp was somehow hidden from the presentationlayer and only present in the data access layer but still would be transfered to and from the database when doing updates etc.

Best of all I could use a working example.

Thanks in advance :-)

There is a big difference between DateTime and Timestamp, the former is a data type while the late is a derived data type SQL Server uses internally for housing keeping. So Timestamp will not move with your data. Try the link below for a tutorial on concurrency. Hope this helps.

http://www.15seconds.com/issue/030604.htm

|||

Thanks for you reply.

I know there is a big difference between the two datatypes but that is not my problem - my problem is HOW to use one of them.

You are wrong about that "timestamp vil not move with your data" - what I've done to overcome my Byte[] problem is to cast the timestamp to char(8) - when I later want to make an update I compare with the timestamp (which is casted back from char(8) to timestamp). This works like it should but I just don't like this casting thing - there must be a better way.

I've allready read the artickel you've linked - among a lot of others. This one is unfortunally in VB which is not my strong side. Is there another one in C# that you know of?