Forum Discussion

sstevens's avatar
sstevens
New Contributor
7 years ago

JDBC Response date format assertion diffs that dont include ".0" at the end of the string

Im perplexed by an issue with regards to JDBC Test Step responses

 

It is specific to the Response XML on date columns:

 

The JDBC response XML:

 

<Results>
   <ResultSet fetchSize="10">
      <Row rowNumber="1">
         <E_REVISION_DATE>2015-02-27 00:00:00.0</E_REVISION_DATE>

 

For as long as I can remember Ive had assertions to check that the date column above is correct

 

Now the XPath Match assertion is diffing with:

[XPath Match] The XPathContains assertion failed for the following path: [//Results[1]]. Class name: Exception; Error Message: org.custommonkey.xmlunit.Diff

[different] Expected text value '2015-02-27 00:00:00.0' but was '2015-02-27 00:00:00'

 

Odviously the diff is the ".0" at the end

 

Why all of a sudden are ALL of my dates diffing on this type of assertion failure?

 

Is there a ReadyAPI [property/or setting that is determining the date format that is output from the JDBC Response?

 

Any and all recommendations are appreciated

 

Using ReadyAPI 1.9.0

6 Replies

  • Nastya_Khovrina's avatar
    Nastya_Khovrina
    SmartBear Alumni (Retired)

    Hi sstevens, 

     

    Thank you for your post. Did you check the date format in your Database? If you run a request in the DB in which format will you receive it?

  • skelander's avatar
    skelander
    Occasional Contributor

    Hello!

     

    I am having the exakt same problem. I am using ReadyAPI 2.2.0.

     

    When executing the same sql via Oracle SQL Developer (we are runing Oracle Database 12c) I get the date without the .0 in the end.

     

    Not a big problem, but slightly annoying :)

     

     

    Cheers,

    Rikard

    • Nastya_Khovrina's avatar
      Nastya_Khovrina
      SmartBear Alumni (Retired)

      Hi,

       

      If a value has the Date format in the Database (i.e. 2018-05-23 00:00:00), the JDBC Test Step Request will return it with ".0" in the Response. Java returns it in a such format and ReadyAPI doesn't support formatting dates, taken from the DB.

      As a workaround, you can write the desired format in the SQL Query, for example:
      Select TO_CHAR(PATH, FORMAT)

       

      where PATH - SQL path to the field, which needs to be formatted
      FORMAT - the needed date format, for example: 

      'YYYY-MM-DD HH24:MI:SS' 

       

      • richie's avatar
        richie
        Community Hero

        Hi,

         

        that will help skelander, because he's using Oracle - but sstevens didn't mention the RDBMS he's using.

         

        If sstevens is using a different RDBMSs then this won't work will it?

         

        if it's SQLServer you might have to use the CONVERT method or getDate or something like that.

         

        Cheers,

         

        richie

  • sstevens's avatar
    sstevens
    New Contributor

    Hey Everybody

     

    I am using Oracle RDBMS

     

    I incorporated a workaround for the issue using a regular expressions in the assertion where the expected date result was being checked

     

    i.e.

    2008-09-12 12:00:00*

     

    The assertion was specifically hardcoding the .0 at the end of the string:

    2008-09-12 12:00:00.0

     

    Which IS NOT smart in my opinion anyway---

     

    For my purposes this is ok

     

    The real issue with this was that Ready API JDBC response was including the ".0" at the end of the string when running on Machine X and when getting the same JDBC response on Machine Y the ".0" WAS NOT showing up

     

    The wildcard for the .0 takes care of that issue for my circumstances

     

    But I never really got a great answer as to WHY this would happen

     

     

    • richie's avatar
      richie
      Community Hero
      hi,

      difference in environmental config im guessing between the 2 machines.

      same versions of readyapi!, java, .jar driver files for the oracle thin driver?

      gotta be something like that right?

      cheers,

      richie