February 14, 2011 at 8:23 am
Thanks I'll try it out later.
February 14, 2011 at 6:35 pm
Ok... I'll be the one to ask...
Why not validate and mark all the failures at once using set based SQL? Then you could actually create a report instead of possibly having a million rows of RAISERROR results.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 15, 2011 at 7:20 am
Jeff Moden (2/14/2011)
Ok... I'll be the one to ask...Why not validate and mark all the failures at once using set based SQL? Then you could actually create a report instead of possibly having a million rows of RAISERROR results.
Very good idea Jeff! 🙂
Thanks!
February 15, 2011 at 7:24 am
I don't know if Grasshopper wants to only display the subprojects that aren't null or not create the report at all if any of the subprojects are null. If it's the latter, Grasshopper can continue checking the rest of the subprojects based on the previous subproject's @RetVal value. If the @RetVal = 'NotNull' then check the next subproject. If @RetVal = 'NULL' then there's no need to check the rest of the subprojects.
February 15, 2011 at 7:33 am
konstantinos.christodoulakis (2/15/2011)
Jeff Moden (2/14/2011)
Ok... I'll be the one to ask...Why not validate and mark all the failures at once using set based SQL? Then you could actually create a report instead of possibly having a million rows of RAISERROR results.
Very good idea Jeff! 🙂
Thanks!
Isn't that exactly what you rejected earlier in this thread?
konstantinos.christodoulakis (2/13/2011)
mister.magoo (2/13/2011)
There is... but why are you opposed to just returning the dataset containing the problem subprojects?The case is the following:
On a .NET app I have a button with which a SP is executing and creates an XML Exported file.
So I created a SP with a very big query to export the XML using FOR XML PATH.
During execution of SP, I need to check every field (there are almost 100 fields) and verify that there are NO NULL values.
So the case I described with SUBPROJECT START DATE is only one of my cases.
I have a lot of other cases with checks on another tables with other subqueries.
So, I believe that to post here the whole DDL will be more confusing than helpful.
Do you have any other idea to help me out?
MM
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);
February 15, 2011 at 7:27 pm
mister.magoo (2/15/2011)
konstantinos.christodoulakis (2/15/2011)
Jeff Moden (2/14/2011)
Ok... I'll be the one to ask...Why not validate and mark all the failures at once using set based SQL? Then you could actually create a report instead of possibly having a million rows of RAISERROR results.
Very good idea Jeff! 🙂
Thanks!
Isn't that exactly what you rejected earlier in this thread?
konstantinos.christodoulakis (2/13/2011)
mister.magoo (2/13/2011)
There is... but why are you opposed to just returning the dataset containing the problem subprojects?The case is the following:
On a .NET app I have a button with which a SP is executing and creates an XML Exported file.
So I created a SP with a very big query to export the XML using FOR XML PATH.
During execution of SP, I need to check every field (there are almost 100 fields) and verify that there are NO NULL values.
So the case I described with SUBPROJECT START DATE is only one of my cases.
I have a lot of other cases with checks on another tables with other subqueries.
So, I believe that to post here the whole DDL will be more confusing than helpful.
Do you have any other idea to help me out?
Heh... it's all "in the wrist". 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
February 16, 2011 at 12:52 am
Hi,
Can you try this SQL.
if Exists (select COUNT(*) from PROJECT Inner join SUBPROJECT ON PROJECT.ID = SUBPROJECT.ID
Where (PROJECT.ID=@IDProject)
and Subproject.StartDate is null) > 1
BEGIN
RAISERROR ('Subproject Start Date cannot be NULL.',11, 2) WITH NOWAIT
END
February 16, 2011 at 2:28 am
Jeff Moden (2/15/2011)
Heh... it's all "in the wrist". 😛
I wouldn't mind if the rejection of that idea hadn't meant I spent time looking for other ways...:crazy:
MM
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply