Jason Wharton schrieb:

> What I can do is change the behavior and then have a property at the
> connection level that enables someone to revert it back to the old way of
> dong things.

What I don't like in changing default behaviour is, that it won't break
anything in applications that don't use the current version of IBO but
will do as soon as one switches in the future.
Since there is no chance to prepare the code for that in advance it will
just break with a new IBO version.

Of course the forum and the archive will be of quick help, but
nevertheless I doubt that in a big app you can check anything in
advance, and surely this is a pitfall. And surely it will happen at
customer site, first (if ever).

And this was my *it's the user's fault* about.

In fact I don't like calling a string truncation function before
assigning a parameter value which will call a string truncation function
(at least so far).

I don't see any big difference to re-publishing the MaxLength property
in an TIB_Edit.

> A thought that just came to me is, wouldn't it be cool if I made a call to a
> stored procedure (and if it doesn't exist just ignore things) that allows
> someone to return configuration settings for a connection so that people
> wouldn't even have to recompile their applications.

Nice idea.

It's something I'm using in my databases as well. Store some information
about the behaviour, telling the application to change some settings
internally for better work...

> Perhaps this is overkill but it would be a way this could be dealt with as
> painlessly as possible for users.

I do prefer a solution like this because it will give an easy way to
store IBO settings, minimizing problems with new settings, default
behaviour, etc.


Luc.