Hey mrdwprice
yup! looks like the same/very similar issue except I think 678 was using a flat file datasource rather than a jdbc connection or at least that was my interpretation when i tried answering his post.
obviously theres a problem where the datasource is extracting a value '-4dc' rather than a boolean ( true/false or 1/0) during its multi threading (in parallel mode).
what exactly is your JDBC Datasource step actually doing? Is it running a query which builds up a dataset (e.g. repeated rows of data for subsequent use in a test loop?). Are you using this to execute a stored proc to build a dataset?
I was curious about this issue when 678 found it and Im just as curious now, cos essentially i dont really understand why the issue is occurring. Normally I can follow why an error response is generated, but in this regard I dont. Reason for my confusion - your jdbc datasource is extracting data (albeit sourced from CHAR, VARCHAR, NUMERIC, BOOLEAN or whatever table attributes). The error reports a non boolean value trying to (it would appear) write to a boolean attribute. HOWEVER - you are extracting data - youre not writing to a temporary table or anything like that are you? My confusion comes from the fact that ReadyAPI! properties are not cognizant of different datatypes - properties are text unless you specify differently so your ReadyAPI! properties wouldnt have boolean types - would they?
I digress - you can do more investigation (to try and nail down exactly what is going on), but at this point Id raise a Support Ticket. This is obviously a problem with the threading (678's support ticket is #00343467) and I had a quick look to see if I could access the ticket but I couldnt (and Id be surprised if I could - I wouldn't have thought Smartbear would want the public to be able to see their employees comments on support tickets). I dont know what version 678 was running when he found this issue but it was 18months ago - so it couldve been around v2.7.0.
In the meantime - is there a reason running in parallel is essential rather than running in sequence?
you could do some investigation (query your database to identify which table attributes are actually boolean and to determine which table attributes have a value of '-4dc', but Id guess that boolean invalid value of '-4dc' changes each execution run - but at least you might be able to see which table attributes are being mistranslated.
Are you using datasource loop test cases? Or are you using non looped test cases or a mixture of both?
Are the errors occurring on the looped test cases or the non looped ones?
Im wondering if theyre not looped test cases, if you could name the datasource test steps in each of your testcase something different, so the step itself isn't getting mixed up in the memory when the tests are executed in parallel. i.e. in testsuite1, testcase1, datasource would be name datasourceS1C1. in testsuite1, testcase2, datasource would be named datasourceS1C2, etc, etc.
This is a longshot I know - but perhaps if the datasource is named differently to the other datasources in different testcases and testsuites then it wont be muddled in the memory which might help? Longshot I know - and this wouldnt help if youre using looped test cases, but something similar to this solved my very similar issue when I was performance testing in Jmeter, so perhaps this will help?
Thats all I got - but the first thing Id do is raise a ticket. Smartbear will probably tell you to upgrade your ReadyAPI! version, but still its worth raising.
If you could share your project and provide an ERD for the tables youre sourcing from - I could try and replicate the issue on my local machine - I seriously doubt youll be able to share your project - but the offers there if you want.
Sorry I cant be of more help!
Cheers,
rich
