Skip to main content
S
sgobi1-Visitor
1-Visitor
June 9, 2016
Solved

Issue with DateTime picker

  • June 9, 2016
  • 4 replies
  • 4097 views

Hi

We are trying to map DateTime picker to a DateTime Input parameter to use in SQL queries.

It is working fine when a Date is selected.

It does not work when nothing is picked.

Appreciate any help and comments

TIA
Sabarish

Best answer by qngo

You would need another service which verify the datetime input before calling the SQL query service. When nothing is picked in DateTimePicker, you can decide to give a default value as input for SQL query.

4 replies

I
ibanham1-Visitor
1-Visitor
June 10, 2016

Have you tried adding a default value for the date/time input parameter for your SQL service?

S
sgobi1-VisitorAuthor
1-Visitor
June 10, 2016

No. I don't have a default value. I don't want a default value in my target table.

I will still try adding a default value to see if that helps.

Thanks

N
nkhose1-Visitor
1-Visitor
June 10, 2016

As datetime picker only has the changed event you can do the following

a) First give any default value through service which will be binded to Mashup Load Event

b) Then when the default value service is completed i.e ServiceInvokeCompleted you bind that to the SQL service you are now using on date time picker

changed Event

See below

5926269922836480.png?k=bAjheUNz0fw0ydO4fn986MGViF0

Whole Scenerio below 

5463329356644352.png?k=IX5S3k9ythzGZx74hRRBSZVxPAA

Q
qngo1-VisitorAnswer
1-Visitor
June 10, 2016

You would need another service which verify the datetime input before calling the SQL query service. When nothing is picked in DateTimePicker, you can decide to give a default value as input for SQL query.

    R
    rpallares1-Visitor
    1-Visitor
    February 3, 2017

    Hi,

    We had the same problem. For us the best solution was to create a search context with an infotable.

    The binding works well through the infotable even if the date picker is undefined.

    That problem is cleaner to encapsulate the entire search form. As seen, it's safer.

    It allow too to pass the context through mashup parameters correctly, that is not working well with simple datetime data type.

    Using a default value in services was not a good solution in our case.

    Terms & ConditionsAccessibility statement