Wednesday, February 23, 2005

Losing your mind - Part 2

A follow up to my previous post about our Electronic Service Request (ESR).

Monday while we were off for Washington's Birthday ( stated as 3rd Monday in February in statute), I received the following from Lotus Application Development regarding our ESR.

Could you please send me the code that is being interpreted as syntactically correct? I think it would be easier to reproduce your problem using your code. A copy of your database, or a design-only copy of your database would be even better! If you are able to send me a copy of your database, please let me know exactly where to find that code(the name of the field, etc).

If you have any questions, please don't hesitate to contact me. If I don't hear from you, I will follow up with you on Wed., 2/23.

I received the following e-mail this morning.

I was wondering if you received my email sent on 2/21. I've forwarded it to you (see below) for your convenience. To recap, I would like for you to send me the code that is being accepted as syntactically correct so I can reproduce your problem here.

If you have any questions, please contact me. If I don't hear from you, I'll follow up with you on Friday, 2/25.

I sent her a reply mentioning that the developer that found the problem was out yesterday and that we would get something to her today.

I was a bit surprised to see the request though as it seemed pretty straight forward. I wasn't going to send the database we are working on out the door, so the developer went ahead and mocked up a formula in an queryopen and postopen and we sent a database. Easy enough.

I e-mailed the database around 11:30am:

As we are able to re-create the issue within any database having the formula in the postopen and queryopen we are just sending a simple database used to illustrate this and not the original database we were using when we stumbled upon the problem. We did verify that we have this issue with this database. Simply open the "View with event code" in designer and look at the queryopen or postopen. Simply edit the formula to make it syntactically incorrect (remove last parenthesis for example), hit the check mark and save, then move away from it and go back and you will see that it did not keep the change. It does not indicate that the code is incorrect. As mentioned if you make a change that does not contain an error it will save just fine.

Instructions were additionally put in the database.

By 2:50pm, I received the following:

I successfully reproduced the issue in 6.5.3 and triaged this call. This will add to the weight of the SPR GFLY57ZRY8. I will keep you informed of any updates to this SPR.

Please contact me if you have any questions.

Hopefully we'll see the fix at some point. 6.5.4 is already in Code Freeze.


Bob Obringer said...

Sounds like they were really responsive, whether or not they really needed everything they asked for. You had a problem... and they were determined to fix it.

Did this seem like an improvement on their responsiveness in the past?

It might not be fixed yet but at least now you know you haven't really lost your mind!

bonj said...

Yes, it was an improvement and I can't really fault them for the information requested, it just seemed as though someone in such a position would have been able to reproduce rather quickly without anything additional. I could simply be a bit naive about that. Just being on an Intel platform these days seems to make things quicker as people would often get hung up on the platform whenever you would say you were running on the mainframe. As this was not Severity 1 issue the responsiveness was more than adequate.

And having developers with good mental health - Priceless.