I think I'll reply on a snippet of your posting, as I've already said what I had to say [:)]

fregas

FransBouma

 
Of course things are debatable, and I agree with you that returning 'null' would have been better, as I've said a dozen times already. I also explained why that wasn't an option, and I hope that's all clear now. You also forget to mention you talk about a version which is more than a year old (before feb 2004)

 

Sorry, I thought we were still discussing my particular experience with you and your product, on that particular version.  I was merely responding to your posts about what we could do or not do at that particular time.  You seemed frustrated that we just didn't just obsessively check for "empty" objects all over the place (both back when I had originally emailed you about the issue, and now on the forums.)  I was also explaining why I think it was a more serious issue than you gave credit to at the time.

True. Although there's not a lot of difference between:
[code]CustomerEntity c = myOrder.Customer;
if(c.Fields.State!=EntityState.Fetched)
{
    // doesn't exist
}
[/code]
and
[code]
CustomerEntity c = myOrder.Customer;
if(c==null)
{
    // doesn't exist
}
[/code]
You always have to check, no matter what. If you don't check c if it's null, you'll run into other problems. That's why I didn't make it a big deal as well, checks were necessary. Though let's close this now, it's water under the bridge and we've said what we had to say about this[;)]

FransBouma

 
Again, I'm sorry your experience isn't as nice as you'd expected, though much has changed since you've used it. But if you think XML files are the way to go, go ahead, I think you'll learn they have major drawbacks too. :)

No we actually did ask for some hot fixes, downloaded them based upon your suggestion and could never get them quite right.  Some of the issues we emailed you about, and some of it we did not.  We ran out of time and just had to work around the issues.  Also, you're outside the U.S. so I think the time difference made communcation more difficult. 

Could be, but I can't remember a day where we replied after 24 hours to a customer's support call. A time difference always is a problem, but not as big as you make it out to be. You mention here, again, that you never could get the hotfixes or upgrades right. I'm sorry, but if I download a fix for a 3rd party product I use and the fix doesn't work, I mail the vendor, till it works OK. I think that's normal.

To be honest, we kind of gave up on you a bit when you didn't take the "NULL object" issue more seriously when I had emailed you about it.  Your response was something along the lines of "read the documentation" and it didn't sound like you were ever going to fix it.  So I gave up emailing you issues, because this kind of left a bad taste in my mouth.  That was probably wrong of me, since you were only minimizing the importance of that one particular issue (which as you mentioned, has since been fixed), not telling me to not communicate with you at all.

I'm sorry if you felt been threated rudely, as that was nor is ever my intention. The thing is, if that happens again, just say so. Not communicating with a vendor about issues is of course not good.

There were some issues we simply did not report, because we couldn't wait for a response.  I find this VERY, VERY common in software development. Users using your product will not report many bugs, simply because of the perceived time it would take to explain and wait for a solution, especially if they feel they've been talked down to.  More commonly, they will work around the issues, or quit using the product, especially if those users happen to be developers.

You think? If I don't report a bug to a 3rd party vendor, I then also give up the right to complain about it. No offence but it was you who brought up not only an old issue in an old version but also did you say there were other major issues. I won't deny we had our share of major bugs in the product, as every software product has bugs and which get fixed and everyone moves on. The thing is that if you run into an issue, and you don't report it, for whatever reason, IMHO you then also give up the right to complain about them.  Just report them, even if you can't wait for a fix.

Again, Frans I don't mean to make you defensive.  I'm just telling you (and others) what my experience with the product and support was at that time.  I think an O/R mapping product is a huge undertaking that I personally don't think I could manage alone.  I give you credit for having solved a lot of the mapping problems very elegantly, even in that older version.  I didn't start this thread to bash your product, but was telling people what I thought were major problems when I used it so they could give me possible alternatives.

But I then wonder: what was your intention in doing so? You post about a flaw in an old version, clearly about frustration and I understand that completely. Then later on mention 'major other issues' which are not always reported to us, plus you again say you couldn't work with the fixes we supplied. It's your right to vent about whatever you like of course, that's not why I write these postings here. What I want to achieve is that your bad customer experience is turned into a better customer experience, by explaining my reasons and also by giving hints how to improve future communication.

Because no matter which vendor's product you'll pick for your future project(s), if you don't communicate what's on your mind, it won't work out. [:)]