January 12, 2012 at 5:51 am
I would like to be able to do this. Thanks.
January 12, 2012 at 6:29 am
Check this :
http://msdn.microsoft.com/en-us/library/ms191250.aspx
A computed column is computed from an expression that can use other columns in the same table. The expression can be a noncomputed column name, constant, function, and any combination of these connected by one or more operators. The expression cannot be a subquery.
January 12, 2012 at 6:37 am
What exactly are you trying to accomplish here?
If you give us more details and examples, we may be able to suggest an alternative.
January 12, 2012 at 6:41 am
It is in relation to another post where we want to move image data to another linked table. We wanted to automatically get the linked data (currently in the same table). I think we may be able to return data from a linked table via a UDF containing a TSQL select statement....
January 12, 2012 at 6:53 am
What you want to do is not the definition of a computed column. Computed columns aggregate data from other columns. What you're wanting to do is insert data into a column from a proc or UDF, which is more than achievable.
You might be able to use a linked server with a stored procedure that does the INSERT inside the stored procedure. But if the hardware is having issues (like I suspect it is) this may cause you just as many problems as the backup / restore option.
January 12, 2012 at 8:42 am
kevin.smith-1067125 (1/12/2012)
It is in relation to another post where we want to move image data to another linked table. We wanted to automatically get the linked data (currently in the same table). I think we may be able to return data from a linked table via a UDF containing a TSQL select statement....
Wouldn't you just create a VIEW to join the two tables? The data, as seen through the view, would look exactly like the original table, and performance will be very good.
It is technically possible to define a computed column that uses a function to access data, but that is always a bad idea. Not only is it much more work, the function will be executed once per row, so if you select 100 rows from the first table in a single query, the function (and it's hidden SELECT statement) will execute 100 times, just as if you had written 100 different queries. Needless to say, this does not perform or scale well at all.
January 12, 2012 at 8:47 am
Thanks guys
January 12, 2012 at 9:05 am
Paul,
The rest of the discussion is happening here: http://www.sqlservercentral.com/Forums/Topic1234678-391-1.aspx
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply