Forum Discussion

electric_Insura's avatar
electric_Insura
Contributor
11 years ago

[R] New JDBC/Data Connection Data Sources return "clob" data

Hi,

As of SoapUI 4.6.0 and 4.6.2, my JDBC/Data Connection data sources return data in "clob" format. This data isn't readable unless you handle it with Groovy.

When I run exactly the same query in a data source created a few months ago and a data source created yesterday or today, one returns good data and the other (newer) data source returns clob data.

This looks like a bug to me.

8 Replies

  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    Hi,

    When I run exactly the same query in a data source created a few months ago and a data source created yesterday or today, one returns good data and the other (newer) data source returns clob data.


    Which version of SoapUI created the data source that returns "good data" and which version of SoapUI is used to create the DataSource that returns the "clob" data (I guess you mean garbage characters are being returned)?

    Also which JDBC driver are you using?

    Regards,
    Marcus
    SmartBear Support
  • Hi Marcus,

    I am using SoapUI 4.6.2 and jTDS as a driver.

    A couple of notes.


    • If I run the same query in a Groovy script within a text editor, I get the same results - Clob objects.

    • Running the query from within a Datasource I created just now in SoapUI 4.5.2 returns Clob objects.

    • A SoapUI DataSource I created several months ago still returns XML for that query. So I believe something recently got pushed to my desktop without my knowledge that caused this. I have not changed jTDS versions and I've ruled out the likely culprit in terms of desktop changes.

    • If I do the call from within a JDBC request step, I get XML results. However, I can't process these results the way I could if a DataSource returned them, so it doesn't do me any good.


    I'm going to make the recommendation that DataConnection or JDBC DataSources be able to handle Clob objects the same way a JDBC Request test step does.
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    Hi,

    The JDBC Request test step is the preferred way to do JDBC with SoapUI currently.

    Please elaborate on "However, I can't process these results the way I could if a DataSource returned them, so it doesn't do me any good."

    What is the difference between the two in which you cannot process the results?


    Regards,
    Marcus
    SmartBear Support
  • I need to look for particular XPaths and hand each XML off to a different SOAP request depending on its contents.

    I have no idea how to do that with more than one row returned from a table at the same time. You can cycle through each row of a DataSource easily within SoapUI; not so much with a JDBC request. My Groovy scripting skills are limited so that's not really an option.
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    Hi,

    The JDBC test step is designed to return results in XML format.

    If you need to loop through the returned data with a DataSource loop one thing you can do is use the jdbc request, and then use a DataSource and choose XML. Configure the DataSource to use the JDBC test request as the Source step.


    Regards,
    Marcus
    SmartBear Support
  • ResultSet[1]/Row[1]/Column[1] as the Xpath works, but it returns results only for the first row.

    Is there a way to specify an Xpath to get results for all rows?
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    Hi,

    You need to edit the XPATH.

    It should be ResultSet[1]/Row for Row XPath and Column/text() for Column XPath.

    Attached is a screen shot for reference.

    Also this is a good reference for using XML data source.
    http://blog.smartbear.com/api-testing/h ... in-soapui/

    Regards,
    Marcus
    SmartBear Support
  • I have it working now - the DataSource returns the fields for all of the rows that come back from the JDBC request. Thanks Marcus.