December 14, 2018 at 12:08 pm
I have a very straight forward check in a stored procedure that makes sure an EndTime was entered from an application. Everything works fine till i get to midnight, our billing process only allows times in 15 minute intervals so the user is picking from a list that has all the available time values. When the user select 12:00 AM it passes '00:00:00' as a time data type to SQL and below is my check in the stored procedure
if @p_EndTime is null
begin
raiserror('End time cannot be blank',16,1)
return(1)
end
For some reason even though its not passing a null value back its causing the raiserror to run and haven't been able to determine why.
Thanks,
December 14, 2018 at 12:31 pm
We're missing a piece or 3 of the jigsaw here. Yes, that's the SQL that's raising the error, but that is because that variable does have the value NULL. We need to see the application code or the code prior to the SQL above.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
December 14, 2018 at 12:34 pm
Here is the code prior to that call
CREATE PROCEDURE [dbo].[usp_add_TimeCardEntry]
@p_EntryDate date,
@p_TechBranch varchar(3),
@p_TechNo varchar(4),
@p_Tech varchar(50),
@p_WO_Branch varchar(3),
@p_WONo varchar(8),
@p_WONo2 varchar(8),
@p_Customer varchar(50),
@p_Lunch char(1),
@p_Segment800 char(1),
@p_LaborCode varchar(3),
@p_StartDate date,
@p_StartTime time,
@p_EndDate date,
@p_EndTime time
as
if (@p_WONo <> '' and (@p_WONo2 <> '' or @p_Lunch = 'Y'))
begin
raiserror('If My Work Orders is selected no other type can be entered',16,1)
return(1)
end
if (@p_WONo2 <> '' and (@p_WONo <> '' or @p_Lunch = 'Y'))
begin
raiserror('If Other Work Order is selected no other type can be entered',16,1)
return(1)
end
if (@p_Lunch = 'Y') and (@p_WONo2 <> '' or @p_WONo <> '')
begin
raiserror('If Lunch is selected no other type can be entered',16,1)
return(1)
end
if @p_StartTime is null
begin
raiserror('Start time cannot be blank',16,1)
return(1)
end
if @p_StartDate = '' or @p_StartDate is null
begin
raiserror('Start date cannot be blank',16,1)
return(1)
end
if @p_EndTime is null
begin
raiserror('End time cannot be blank',16,1)
return(1)
end
if @p_EndDate = '' or @p_EndDate is null
begin
raiserror('End date cannot be blank',16,1)
return(1)
end
if @p_LaborCode = '' and @p_Lunch <> 'Y'
begin
raiserror('Labor Code must be entered',16,1)
return(1)
end
if @p_StartTime > @p_EndTime and @p_StartDate > @p_EndDate
begin
raiserror('Start Date / Time must be less than end time',16,1)
return(1)
end
if @p_EndTime < @p_StartTime and @p_EndDate <= @p_StartDate
begin
raiserror('Start Date / Time must be less than end time',16,1)
return(1)
end
if exists (select TechNo from cv_TechTimeCard where TransactionType = 'Lunch' and Status = 'TP' and TechNo = @p_TechNo) and @p_Lunch = 'Y'
begin
raiserror('You have already entered a lunch entry for today no other lunch entries can be made',16,1)
return(1)
end
December 14, 2018 at 12:34 pm
lucaskhall - Friday, December 14, 2018 12:08 PMI have a very straight forward check in a stored procedure that makes sure an EndTime was entered from an application. Everything works fine till i get to midnight, our billing process only allows times in 15 minute intervals so the user is picking from a list that has all the available time values. When the user select 12:00 AM it passes '00:00:00' as a time data type to SQL and below is my check in the stored procedure
if @p_EndTime is null
begin
raiserror('End time cannot be blank',16,1)
return(1)
endFor some reason even though its not passing a null value back its causing the raiserror to run and haven't been able to determine why.
Thanks,
As this code runs without executing the SELECT, there must be something happening with the setting of @p_EndTime:
DECLARE @p_EndTime TIME = '00:00:00';
IF @p_EndTime IS NULL
BEGIN
SELECT 'End time cannot be blank';
END;
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
December 14, 2018 at 12:38 pm
This is the application code that is generated when the stored procedure is called and resulting in the "End time cannot be blank" error
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57|Performing Action XML: <Request>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <ExecuteJDBCProgram>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Name>usp_add_TimeCardEntry</Name>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <ParameterList>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='Date' length='10' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[2018-12-14]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='String' length='3' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[300]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='String' length='4' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[1541]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='String' length='50' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[lucas.hallcv]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='String' length='3' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[300]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='String' length='8' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[488025]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='String' length='8' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='String' length='50' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[ALTRONIC]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='String' length='1' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[N]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='String' length='1' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[N]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='String' length='3' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[001]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='Date' length='8' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[2018-12-14]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='Time' length='8' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[22:00:00]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='Date' length='8' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[2018-12-14]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='Time' length='8' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[00:00:00]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </ParameterList>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </ExecuteJDBCProgram>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57|</Request>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57|Using Pooled Data Source for sa(jdbc:sqlserver://EBSSQL:61630;databaseName=Catavolt_Test)
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Preparing program call: {call usp_add_TimeCardEntry(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)}
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm: 2018-12-14
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm: 300
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm: 1541
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm: lucas.hallcv
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm: 300
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm: 488025
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm:
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm: ALTRONIC
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm: N
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm: N
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm: 001
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm: 2018-12-14
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm: 22:00:00
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm: 2018-12-14
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| Parm: 00:00:00
December 16, 2018 at 10:05 am
Disclaimer: I don't know beans about Java 😀 but the code looks correct for ordinal position of the inputs and the number of inputs (15) in all sections.
The only way that I can see a problem like what you're experiencing is ...
1. The application is actually pointed at the wrong server or database and the dbo.usp_add_TimeCardEntry stored procedure is different there or...
2. There's an identically named stored procedure on the same database instance but in a different schema. Since the Java code doesn't provide a schema name in the call, could it be calling one of those other identically name copies based on the the current user connection?
3. Have you made sure that the Catavolt_Test database has the exact code that you actually posted?
As a bit of a sidebar and with proper observation of my disclaimer, it looks like your application is using the SA login. If that's true, you are making a fatal error and will eventually end up reading about yourself in the morning news one day.
As another sidebar, it still amazes me that even in this day and age (and over the last 3 decades) of being able to easily do temporal calculations to the millisecond that there are still applications out there that require 15 minute intervals (or any interval, for that matter) for time entries. Even old punch-timecard machines didn't fetter the users in that manner.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 16, 2018 at 12:18 pm
Jeff Moden - Sunday, December 16, 2018 10:05 AMEven old punch-timecard machines didn't fetter the users in that manner.
Careful, Jeff. You may awaken the kraken.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
December 16, 2018 at 12:46 pm
Phil Parkin - Sunday, December 16, 2018 12:18 PMJeff Moden - Sunday, December 16, 2018 10:05 AMEven old punch-timecard machines didn't fetter the users in that manner.Careful, Jeff. You may awaken the kraken.
Heh... nah... rumor has it that he's too busy trying to fill out his timesheet 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2018 at 5:32 am
In response to your concerns regarding how time is handled in this case our back end system and billing is conducted using 15 minute intervals. On the technician side when they are filling out a time card they are using IOS devices that has a selector where they can pick from all the 15 minute intervals in a day. It would have been easy like you said to just do the conversion but there is no button or action based scenario that captures time (mostly due to so many variables in billing i.e when time starts and ends), the technician could fill out his time card as he does jobs or at the end of the day so had to allow them to pick time rather than time being set by an action.
In terms of the SA account usage this is in my development environment and yes I need to disable it and just create a service account but i assure you this is not the case in my production environment.
Lastly in terms of the below questions yes its pointed at the right server , there is no identical stored procedure and not another stored procedure in a different schema. even replacing the is null with as check for '' results in the same.
The only way that I can see a problem like what you're experiencing is ...
1. The application is actually pointed at the wrong server or database and the dbo.usp_add_TimeCardEntry stored procedure is different there or...
2. There's an identically named stored procedure on the same database instance but in a different schema. Since the Java code doesn't provide a schema name in the call, could it be calling one of those other identically name copies based on the the current user connection?
3. Have you made sure that the Catavolt_Test database has the exact code that you actually posted?
December 17, 2018 at 8:05 am
lucaskhall - Friday, December 14, 2018 12:38 PMThis is the application code that is generated when the stored procedure is called and resulting in the "End time cannot be blank" errorFINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57|Performing Action XML: <Request>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <ExecuteJDBCProgram>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Name>usp_add_TimeCardEntry</Name>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <ParameterList>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='Date' length='10' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[2018-12-14]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='Date' length='8' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[2018-12-14]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='Date' length='8' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[2018-12-14]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </ParameterList>
The length of your @p_StartDate and @p_EndDate parameters is defined as '8' where parameter @p_EntryDate is defined as '10' and they are all 'Date' data types. That might be causing a misalignment of parameters.
December 17, 2018 at 8:07 am
lucaskhall - Monday, December 17, 2018 5:32 AMIn response to your concerns regarding how time is handled in this case our back end system and billing is conducted using 15 minute intervals. On the technician side when they are filling out a time card they are using IOS devices that has a selector where they can pick from all the 15 minute intervals in a day. It would have been easy like you said to just do the conversion but there is no button or action based scenario that captures time (mostly due to so many variables in billing i.e when time starts and ends), the technician could fill out his time card as he does jobs or at the end of the day so had to allow them to pick time rather than time being set by an action.In terms of the SA account usage this is in my development environment and yes I need to disable it and just create a service account but i assure you this is not the case in my production environment.
Lastly in terms of the below questions yes its pointed at the right server , there is no identical stored procedure and not another stored procedure in a different schema. even replacing the is null with as check for '' results in the same.
The only way that I can see a problem like what you're experiencing is ...
1. The application is actually pointed at the wrong server or database and the dbo.usp_add_TimeCardEntry stored procedure is different there or...
2. There's an identically named stored procedure on the same database instance but in a different schema. Since the Java code doesn't provide a schema name in the call, could it be calling one of those other identically name copies based on the the current user connection?
3. Have you made sure that the Catavolt_Test database has the exact code that you actually posted?
Thanks for those answers and understood on the 15 minute interval thing. It would be nice if third parties would finally figure out this is the 21st century.
As I previously disclaimed, I don't know much of anything about Java. From what you posted, everything looks correct and should be working. The stored procedure code doesn't appear to be at fault but it would be good to print the contents of the parameters at the top of the procedure to see what is actually being received by the proc just to be sure. If I were sitting in your chair, that would be my next step in this.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2018 at 10:21 am
scottmildenberger - Monday, December 17, 2018 8:05 AMlucaskhall - Friday, December 14, 2018 12:38 PMThis is the application code that is generated when the stored procedure is called and resulting in the "End time cannot be blank" errorFINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57|Performing Action XML: <Request>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <ExecuteJDBCProgram>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Name>usp_add_TimeCardEntry</Name>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <ParameterList>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='Date' length='10' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[2018-12-14]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='Date' length='8' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[2018-12-14]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='Date' length='8' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[2018-12-14]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </ParameterList>The length of your @p_StartDate and @p_EndDate parameters is defined as '8' where parameter @p_EntryDate is defined as '10' and they are all 'Date' data types. That might be causing a misalignment of parameters.
I don't think its so much misalignment as simply truncation meaning that 2018-12-14 is being truncated to 2018-12- in the XML schema As this isn't a valid date the SP is getting NULL passed to it.
December 17, 2018 at 3:45 pm
crmitchell - Monday, December 17, 2018 10:21 AMscottmildenberger - Monday, December 17, 2018 8:05 AMlucaskhall - Friday, December 14, 2018 12:38 PMThis is the application code that is generated when the stored procedure is called and resulting in the "End time cannot be blank" errorFINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57|Performing Action XML: <Request>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <ExecuteJDBCProgram>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Name>usp_add_TimeCardEntry</Name>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <ParameterList>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='Date' length='10' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[2018-12-14]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='Date' length='8' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[2018-12-14]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Parameter type='Date' length='8' direction='IN'>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| <Value><![CDATA[2018-12-14]]></Value>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </Parameter>
FINEST|9864/0|Service cvsat-v3.521.3-dev|18-12-14 13:35:57| </ParameterList>The length of your @p_StartDate and @p_EndDate parameters is defined as '8' where parameter @p_EntryDate is defined as '10' and they are all 'Date' data types. That might be causing a misalignment of parameters.
I don't think its so much misalignment as simply truncation meaning that 2018-12-14 is being truncated to 2018-12- in the XML schema As this isn't a valid date the SP is getting NULL passed to it.
Good eyes... I didn't check the other "fields" for length.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2018 at 2:46 am
Jeff Moden - Monday, December 17, 2018 3:45 PMcrmitchell - Monday, December 17, 2018 10:21 AMscottmildenberger - Monday, December 17, 2018 8:05 AMThe length of your @p_StartDate and @p_EndDate parameters is defined as '8' where parameter @p_EntryDate is defined as '10' and they are all 'Date' data types. That might be causing a misalignment of parameters.I don't think its so much misalignment as simply truncation meaning that 2018-12-14 is being truncated to 2018-12- in the XML schema As this isn't a valid date the SP is getting NULL passed to it.
Good eyes... I didn't check the other "fields" for length.
To be fair its Scott that has the good eyes.
December 18, 2018 at 7:43 am
crmitchell - Tuesday, December 18, 2018 2:45 AMJeff Moden - Monday, December 17, 2018 3:45 PMcrmitchell - Monday, December 17, 2018 10:21 AMscottmildenberger - Monday, December 17, 2018 8:05 AMThe length of your @p_StartDate and @p_EndDate parameters is defined as '8' where parameter @p_EntryDate is defined as '10' and they are all 'Date' data types. That might be causing a misalignment of parameters.I don't think its so much misalignment as simply truncation meaning that 2018-12-14 is being truncated to 2018-12- in the XML schema As this isn't a valid date the SP is getting NULL passed to it.
Good eyes... I didn't check the other "fields" for length.
To be fair its Scott that has the good eyes.
Thanks for the correction. I totally missed it because the only Java I do is what I drink in the morning. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply