You know...

I was just thinking....that I am way overthinking this solution...

I am hung up on ensuring I have a way to touch each db, and trap an error if it...

Thank you for taking the time to respond! I really do appreciate it.

I like using the db_name() instead of dbcc...runs so much faster when I print the results..instead of...

Here is the SQL for my solution...I'm sure there are ways to further optimize it...but its getting things done...10 times faster than my earlier attempts...

The key lessons learned were that...

I was able to rewrite my joins...so they didn't have to be nested....so the correlated sub query is working much faster.....

Thank you again to everyone!!!!

thanks again.

i'm trying to see if I can get the correct transaction record without a nested query.......then a standard correlated subquery will work...but I know there has to be a...

since I have so much time on my hands while this monster crunches data....

I am still working to see if I can find a set based solution...

enter the correlated sub...

Well,

I took the logic you used in you code...I have another field...cycledate...which happens to be indexed..so I built an outer loop structure....and for each cycledate...I process those claims...it's not exactly...

Thanks alot!

I will work with it today...I have plenty of time...since I am letting the previous code crunch data...I'm sure it will take at least all day...

:>)

I love this place...at...

isn't that the sad truth....

damn them once for creating the whole mess...

damn me for not jumping ship as soon as I realize what a steaming pile I jumped head first...

Matt,

Thanks...that is another great idea...I'll work with that tomorrow...see if I can make it work.

I'm fine with all the denormalized tables...for reporting purposes...it makes the data retrieval really quick...but only...

exactly...a bunch of completely denormalized "tables" (term used loosely)

management won't let me change the existing schema...since there is so much already built on top of the existing mess.

So I'm back...

I agree with you 100 percent...if I can figure out a way to make a set based update instead...I would be so happy. I do my best to avoid...

Thank you for taking the time to respond.

You are correct, the Case Logic was lacking....but the Cross Join solution that was offered up...was exactly what I should have been doing...

I noticed that...but my original request stated that if a person served during multiple wars...I would only count the first....so the case logic was sufficient.

But I prefer your cross join...that...

I just implemented your solution, and it is much, much cleaner and easier than using the case logic.

Thanks again

😀

select

a.*

from

...