erizias

197 reputation

111

bio	website
	location	Denmark
	age
visits	member for	1 year, 7 months
	seen	May 24 at 10:42
stats	profile views	13

Stoning a lot of

- ASP Classic
- XHTML
- CSS
- RegExp
- JavaScript
- jQuery
- jQueryUI

	197 reputation	bio	website		visits	member for	1 year, 7 months
111 badges		location	Denmark		seen	May 24 at 10:42

summary answers questions tags badges favorites bounties reputation activity

47 Actions

suggestions reviews revisions comments badges posts accepts all

May 20	awarded	Caucus
May 20	awarded	Constituent
Mar 12	comment	Update Table A row if Table B row is changed Just saw your edit yesterday evening... It helped a lot, thanks! :)
Mar 9	accepted	Update Table A row if Table B row is changed
Mar 9	comment	Update Table A row if Table B row is changed I'm absolutely not dead-set for the trigger-use, I'm just trying to fully understand the alternative given by many of you, and especially how to be using it in my situation. I do think there is a performance problem. Without the subqueries the query takes 2 seconds on 50.000 rows (on my dev machine), and with the subqueries it takes 4 seconds. I just tested the inner join-method and then it takes up to 7 seconds :(
Mar 9	comment	Update Table A row if Table B row is changed I actually didn't know that they deprecated that, thanks! I'll use nvarchar(max) in the future then! :) And I dont "want" to group by the comment column, but the data cannot be displayed without grouping it (I get an invalid column error). But changing the ntext to nvarchar makes it possible. :)
Mar 9	comment	Update Table A row if Table B row is changed @AaronBertrand, I just edited the question with an example on your approach with the inner join. Reading the edit, do You still think this approach is better than the trigger approach?
Mar 9	revised	Update Table A row if Table B row is changed added 2399 characters in body
Mar 8	comment	Update Table A row if Table B row is changed And about the inner join calculation, then there COULD be times where I would have to do 5 or 6 inner joins instead of the current 5 or 6 subcalculations. I think (not knowing) this could be a performance issue?
Mar 8	comment	Update Table A row if Table B row is changed The Table A row are always inserted before Table B rows, by the application. Does this answer the question regarding the Name? If all rows in Table B are deleted, this must not delete the Table A row, but just set the column to either 0 or NULL.
Mar 8	comment	Update Table A row if Table B row is changed I know I didn't give any information about how often the sub-calculations are being used. I didn't think it was relevant. :)
Mar 8	comment	Update Table A row if Table B row is changed I see your point there, but the data are being written/updated 1 time for every 100 times the data are being read. I'm not an expert on query performance, therefore this question. :)
Mar 8	comment	Update Table A row if Table B row is changed Once in a while? This is vital information for the application and are selected A LOT. There are 5-6 different kind of sub-calculations like this, for each select statement. Is that not a performance-issue?
Mar 8	asked	Update Table A row if Table B row is changed
Feb 7	awarded	Peer Pressure
Jun 27	awarded	Popular Question
Apr 26	awarded	Nice Question
Feb 15	awarded	Critic
Feb 15	accepted	Going from separate databases to shared databases and schemas (Multi Tenant Data Architecture)
Feb 15	comment	Going from separate databases to shared databases and schemas (Multi Tenant Data Architecture) @AaronBertrand: I rest my case. I'm gonna use separate databases anyway :) And then I'm gonna use the designer a lot less :) Thanks a lot! :)