So, I have an Apex class that uses version 10.0 of the API (Summer '07) and it references a standard SF field called UserPermissionsAvantgoUser. I can't find reference to this anywhere else but here.

Yesterday (19th May) I started receiving Apex exceptions that stated that the field does not exist, which appears to be true if you look at the meta-data for the user object.

Simple, you might think; just remove the field from the class definition in a sandbox and deploy to production through eclipse. Unfortunately, SF won't let me overwrite the class, because, according to the validation error, the original class in production is referencing a non-existant field. Catch 22...

Apart from breaking a critical web app that we've built around this class, it is also disrupting normal operation of SF because we have triggers firing on contact edits which get stuck in the invalid code, even though the triggers only apply to a subset of contacts. I'm not a happy bunny.

I've raised a support case and hope to hear back ASAP, but was wondering if anyone else has been hit by this silent change to the backwards compatibility of the API? Any workarounds for when you are denied a class overwrite due to invalid code in production?

So, I have an Apex class that uses version 10.0 of the API (Summer '07) and it references a standard SF field called UserPermissionsAvantgoUser. I can't find reference to this anywhere else but here.

Yesterday (19th May) I started receiving Apex exceptions that stated that the field does not exist, which appears to be true if you look at the meta-data for the user object.

Simple, you might think; just remove the field from the class definition in a sandbox and deploy to production through eclipse. Unfortunately, SF won't let me overwrite the class, because, according to the validation error, the original class in production is referencing a non-existant field. Catch 22...

Apart from breaking a critical web app that we've built around this class, it is also disrupting normal operation of SF because we have triggers firing on contact edits which get stuck in the invalid code, even though the triggers only apply to a subset of contacts. I'm not a happy bunny.

I've raised a support case and hope to hear back ASAP, but was wondering if anyone else has been hit by this silent change to the backwards compatibility of the API? Any workarounds for when you are denied a class overwrite due to invalid code in production?