Attributes not updating on Linux, but updating on Mac OS X

[Ramon Cahenzli]

Hi again,

I'm sorry to discuss another issue, but we've invested about 20 person-
hours trying to locate the problem and didn't get anywhere.

Here's the issue: On Mac OS X, with Rails in development or production
mode, a record on our MS-SQL server is fetched, some attributes
changed and then saved. This works.

On Linux, this only works in development mode. In production mode,
almost all attributes are updated as well, except for two seemingly
random ones. We can reliably reproduce this, it always concerns the
same two attributes ("AenderungVon" and "Aenderung", don't ask why the
database dudes thought it's a smart idea to label the data in German).
The other attributes are all written reliably.

We have hooked up a debugger to shortly before the object is saved.
The object, in memory, is correct. When saving, AR (or the adapter)
returns true. AR correctly identifies the changed attributes on this
object. When reloading the object from DB, however, we find out that
the update statement was never correctly built and thus the changed
attributes were never written to DB.

Has anyone ever encountered such behavior? We are meanwhile using
activerecord-sqlserver-adapter 2.2.19 -- we first thought the problem
was in an old version of the adapter.


Behavior in production mode:

UPDATE [Anlass] SET [AnlassMemo1] = 'from the web to the production
system more fishcakes', [IDAnlassStatus] = 100210 WHERE [IDAnlass] =
83596


Behavior in development mode:

UPDATE [Anlass] SET [AenderungVon] = 'someone', [AnlassMemo1] = 'from
the web to the production system more fishcakes monkey', [Aenderung] =
'2009-08-06 17:36:05.070', [IDAnlassStatus] = 100210 WHERE [IDAnlass]
= 83596


The code that updates these attributes (please, please, please ignore
the German. Imagine it's Swahili or something):

def self.write_course(course)
set_table_name "Anlass"
set_primary_key "IDAnlass"

# NOTE check the existing IDAnlassStatus before saving and abort
if not textbearbeitungbis (100n00, n in 1,2)
anlass = first(:conditions => ["IDAnlass = ? AND ((IDAnlassTyp = 2
AND IDAnlassStatus = 100100) OR (IDAnlassTyp = 3 AND IDAnlassStatus =
100200))", course.evento_anlass.IDAnlass])

unless anlass
return false
else
course.edited_descriptions.each do |description|
tempval = utf2iso(description.value).strip
anlass.send("AnlassMemo#{description.evento_position}=",
(tempval.blank? ? nil : tempval))
end

# These are the stubborn ones -- AenderungVon and Aenderung are
NOT updated in the
# production environment.
anlass.AenderungVon = course.main_lecturer.username
anlass.Aenderung = Time.now#.to_formatted_s(:db)
anlass.IDAnlassStatus += 10

is_written_back = anlass.save
course.destroy if is_written_back

return is_written_back
end

end

[Ken Collins]

I doubt this has anything to do with the adapter and is more a rails
issue. For instance do you have dirty support turned on in AR for
production only? Perhaps the columns are not firing the correct dirty
stuff or you have attribute writers that are bypassing AR's dirty
support See:

http://api.rubyonrails.org/classes/ActiveRecord/Dirty.html

- Ken

[Ramon Cahenzli]

Hi Ken,

Thanks for the quick reply.

On Aug 6, 8:06 pm, Ken Collins <k...@metaskills.net> wrote:
> I doubt this has anything to do with the adapter and is more a rails  
> issue. For instance do you have dirty support turned on in AR for  
> production only?

I think dirty support is working correctly: We set a breakpoint
shortly before the AR save and looked at the object before it got
persisted. All changes were listed correctly (looking at model.changes
and model.changed? etc.), it just never saved those changes properly.

But it's a good hint and we will see whether there are any
configuration differences between the environments in that area.

Since it appears between different platforms, could it be that
different native versions of UnixODBC/FreeTDS are the culprit? It
would be a very weird bug to surface, but not impossible. Since you
probably have experience working with both, it would be interesting to
hear what you'd guess.

Ramon

[Ken Collins]

I doubt it. This is most certainly at the ActiveRecrd/AbstractAdapter
level. Looking at your SQL that is built (by AR) I still feel this has
something to do with dirty or the like. Let me know what you find.

- Ken