| Subject | RE: [IBO] TIB_ColumnText and strings that are too long |
|---|---|
| Author | Jason Wharton |
| Post date | 2006-01-11T19:26:33Z |
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.
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.
How would this work? I put a new feature in IBO and I realize it changes
existing behavior that may cause an application to work differently. But, a
developer updates their sources and is not aware of this and compiles and
releases a new version of their application and goes on vacation. A user
hits a problem and the programmer cannot recompile a new application right
away. This would allow a quick change to the stored procedure to tell the
application to work the old way.
Perhaps this is overkill but it would be a way this could be dealt with as
painlessly as possible for users.
Jason
connection level that enables someone to revert it back to the old way of
dong things.
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.
How would this work? I put a new feature in IBO and I realize it changes
existing behavior that may cause an application to work differently. But, a
developer updates their sources and is not aware of this and compiles and
releases a new version of their application and goes on vacation. A user
hits a problem and the programmer cannot recompile a new application right
away. This would allow a quick change to the stored procedure to tell the
application to work the old way.
Perhaps this is overkill but it would be a way this could be dealt with as
painlessly as possible for users.
Jason
> -----Original Message-----
> From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]On
> Behalf Of Christian Danner
> Sent: Wednesday, January 11, 2006 8:34 AM
> To: IBObjects@yahoogroups.com
> Subject: Re: [IBO] TIB_ColumnText and strings that are too long
>
>
> Hi Jason!
>
> >I would like to hear from as many people as possible what
> they think the
> >behavior of IBO should be.
> >
> >Should IBO raise an exception if there is a text assignment
> that is longer
> >than there is storage for it.
>
> In principle in data transmissions potentially abridged messages can't
> be trusted and have to be rejected. If the worst comes to the worst
> the unmutilated text may mean the opposite of the original version, a
> disaster e.g. in applications for medical purposes. Therefore in my
> opinion an exception is indispensable.
>
> Fortunately at least the data aware controls themselves (IB_Edit /
> IB_Memo etc.) prohibit an input too long for the corresponding column.
>
> Christian
>
>
>
>
> ______________________________________________________________
> _____________
> IB Objects - direct, complete, custom connectivity to
> Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
> ______________________________________________________________
> _____________
> http://www.ibobjects.com - your IBO community resource for
> Tech Info papers,
> keyword-searchable FAQ, community code contributions and more
> !
> Yahoo! Groups Links
>
>
>
>
>
>
>