== Why is this an issue?

There is such a thing as software that's too helpful, and that's the case with DB2's implicit casting of host variables used in ``++WHERE++`` clauses. If for instance you compare a varchar column with the value of a numeric host variable, starting with version 10, DB2 will silently convert the numeric value to a string - at a potentially huge performance cost. 


This rule raises an issue when the type of a variable used with a SQL ``++WHERE++`` clause does not match the underlying type of the column to which it is compared.


=== Noncompliant code example

[source,cobol]
----
TODO
----


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Use a "type" variable here to match the "xxx" definition of the column.


=== Highlighting

``++colname = :badHostVar++``


'''
== Comments And Links
(visible only on this page)

=== on 27 Jun 2016, 10:05:03 Pierre-Yves Nicolas wrote:
I think that this rule may overlap RSPEC-3617.

=== on 27 Jun 2016, 21:59:49 Ann Campbell wrote:
Related, but different [~pierre-yves.nicolas]. This RSpec is about how I send data _to_ the DB. RSPEC-3617 is about how I get data _from_ the DB.


They also have different motivations: this is about performance, which could apparently be significantly degraded if you break the rule. RSPEC-3617 is about getting back screwed up data.

=== on 27 Jun 2016, 22:01:57 Ann Campbell wrote:
http://www.idug.org/p/fo/et/thread=42706

http://www.idug.org/p/bl/et/blogaid=274

http://it.toolbox.com/blogs/oracle-guide/minitip-10-implicit-vs-explicit-conversion-16441

endif::env-github,rspecator-view[]
