Then my question is Why is this code inserting only two rows...
My guess is that the conditional inside the loop is only true one time other then the first trip.
Is it possible for you change your insert query to directly via a named query with parameters ie INSERT INTO TABLE2 (PART, LOT) VALUES (:part, :lot)
? Your current approach is an indirect to insert and prone to error, all it would take is someone else changing the CHANGE column in that other table to mess up your inserts in unexpected and hard to trace out ways, or just the CHANGE column not being reset properly etc. If you were inserting the parameters directly you could look at your NamedQuery logs if something went wrong, see what is being told to be inserted and you'd be sure that each system.db.runNamedQuery statement was only inserting one row.
Not to mention what of the case if two clients are running at the same time. That could give you a real headache.
TABLE1 has 4 columns; BARCODE, LOT, PART, CHANGE. When a row is filled out, change is always 0. but when a new lot and part don't match the previous lot and part, the pervious change is updated to 1 so that's why it's in the loop.
I'll try initializing prevLot and prevPart how you recommended
do NOT compare strings with is
!
is
checks if the objects are the same, not if they're equal. Won't work with strings !
It works with None
, because it's a singleton, and even with small numbers (because they're also pre-declared as singletons to make things... I don't know, easier ? faster ?).
I'm not sure if this is reliable, but it prints "900", So I'm guessing numbers up to 900 are singletons and can be compared with is
.
for x, n in enumerate(xrange(3000)):
if x is not n:
print x
break
But strings, never ! You can try with variables, with literals, whatever, it just won't work:
"hello" is "hello"
> False
Unless, obviously, if you want to know if they're the same object.
Extra fun in a Java environment, where there's a configurable boxed Integer cache, iirc. I have no idea whether that affects Jython or not, but I certainly wouldn't want to find out
ughh, thanks for keeping me in line. Gee wizz.