If you’re in the loop, you’ve found that the SalesLogix Provider expects all dates to be in ISO format (Note: to clarify, it was originally expected in ANSI format, but with v6.1 the standard was changed to ISO to account for Oracle). I say “in the loop” because unless you’re paying close attention and possibly active in the SalesLogix BP newsgroups, then you likely never heard of this.
Simple enough to provide a workaround, just pass off any dates to a function to format them as ISO dates before passing and SQL statements off to the provider. But, why should I need to? So instead of just fixing it in the provider, now I have to modify my code in all places where I use a date in a SQL insert or update.
What if you forget a spot? Tough luck. The provider will still allow them into the database, a TEF file will still be created, the TEF file will be synched out to the remotes, but the remote client will *reject* it when it brings in the changes. So it will give you 100% impression that all things are fine and working, no errors, the data will be inserted into the database, but your remotes will never see the data (even though they saw the extra traffic in their sync.
Not a good thing. SalesLogix has provided the workaround of making us format dates as ISO. I’d be fine with that as long as the data would be rejected or an error thrown by the provider if I forgot to do it. As it is now, you’d never know you forgot to do that until remotes complained about missing data. You’d never know it by looking at the data on the LAN, it will exist fine there. How about this, as a general rule of thumb. If it makes it into the database, then make it sync. If there is going to be a problem making it sync, possibly because of an incorrect date format, then don’t let it into the database. At least then you’d know right away what the problem is and you could say “oh yeah, I forgot that whole ISO date thing” and fix it right then. >:(