It sounds like a user mashes some buttons on your application, then in the app you generate the TSQL pass it to SQL Server and then it generates some more TSQL for an update, and then issue that syntax to SQL Server to update records in a table.

The SQL syntax looks fine, I would suggest a slightly different approach.

Rather than generate SQL and pass it to the server, you should evaluate the generated code, I would suspect it is similar every time you generate it. The items that change should be able to be parameterized, and you could store the SQL syntax in a user stored procedure, getting re-use and efficiency / performance gains.

The update statement would also benefit from creating a user stored procedure.

This will also help you with security later on if you find the need. Also later when you want to make changes having the SQL code loosely coupled with your C# code will allow you to skip making change to your C# code, re-compile and re-deploy app code.

If you are not familiar with creating user stored procedures, I would suggest looking for some templates, you'll want to create a header with basic info about the user stored procedure. If you have several database objects you might consider reading about database schema, to make it easier to manage different processes or organizational units within the database, also 'dbo' is boring. Using usp_NameSpace is okay, but don't use Hungarian notation on tables please.

I have also found it helps to keep an excel document up-to-date with application functionality and the usp_ it calls.

It sounds like a user mashes some buttons on your application, then in the app you generate the TSQL pass it to SQL Server and then it generates some more TSQL for an update, and then issue that syntax to SQL Server to update records in a table.

The SQL syntax looks fine, I would suggest a slightly different approach.

Rather than generate SQL and pass it to the server, you should evaluate the generated code, I would suspect it is similar every time you generate it. The items that change should be able to be parameterized, and you could store the SQL syntax in a user stored procedure, getting re-use and efficiency / performance gains.

The update statement would also benefit from creating a user stored procedure.

This will also help you with security later on if you find the need. Also later when you want to make changes having the SQL code loosely coupled with your C# code will allow you to skip making change to your C# code, re-compile and re-deploy app code.

If you are not familiar with creating user stored procedures, I would suggest looking for some templates, you'll want to create a header with basic info about the user stored procedure. If you have several database objects you might consider reading about database schema, to make it easier to manage different processes or organizational units within the database, also 'dbo' is boring. Using usp_NameSpace is okay, but don't use Hungarian notation on tables please.

I have also found it helps to keep an excel document up-to-date with application functionality and the usp_ it calls.

It sounds like a user mashes some buttons on your application, then in the app you generate the TSQL pass it to SQL Server and then it generates some more TSQL for an update, and then issue that syntax to SQL Server to update records in a table.

The SQL syntax looks fine, I would suggest a slightly different approach.

Rather than generate SQL and pass it to the server, you should evaluate the generated code, I would suspect it is similar every time you generate it. The items that change should be able to be parameterized, and you could store the SQL syntax in a user stored procedure, getting re-use and efficiency / performance gains.

The update statement would also benefit from creating a user stored procedure.

This will also help you with security later on if you find the need.

If you are not familiar with creating user stored procedures, I would suggest looking for some templates, you'll want to create a header with basic info about the user stored procedure. If you have several database objects you might consider reading about database schema, to make it easier to manage different processes or organizational units within the database, also 'dbo' is boring. Using usp_NameSpace is okay, but don't use Hungarian notation on tables please.

I have also found it helps to keep an excel document up today with application functionality and the usp_ it calls.

It sounds like a user mashes some buttons on your application, then in the app you generate the TSQL pass it to SQL Server and then it generates some more TSQL for an update, and then issue that syntax to SQL Server to update records in a table.

The SQL syntax looks fine, I would suggest a slightly different approach.

Rather than generate SQL and pass it to the server, you should evaluate the generated code, I would suspect it is similar every time you generate it. The items that change should be able to be parameterized, and you could store the SQL syntax in a user stored procedure, getting re-use and efficiency / performance gains.

The update statement would also benefit from creating a user stored procedure.

This will also help you with security later on if you find the need. Also later when you want to make changes having the SQL code loosely coupled with your C# code will allow you to skip making change to your C# code, re-compile and re-deploy app code.

If you are not familiar with creating user stored procedures, I would suggest looking for some templates, you'll want to create a header with basic info about the user stored procedure. If you have several database objects you might consider reading about database schema, to make it easier to manage different processes or organizational units within the database, also 'dbo' is boring. Using usp_NameSpace is okay, but don't use Hungarian notation on tables please.

I have also found it helps to keep an excel document up-to-date with application functionality and the usp_ it calls.