Subject | Re: [IBO] Another parameter example |
---|---|
Author | Paul Hope |
Post date | 2003-08-07T08:35:11Z |
Jason
I dont beleive the situation is as straight forward as you suggest. I have the same data type (examples with integer and char(1)) and the problem still occurs. I've aslo tried casting each side of the equality to no effect.
Setting FCombineDuplicateParams to False in IBA_UpdateSQL line 210 solves the problem for DeleteSQL. However I dont like this sort of change to the source because I wont see an error if it gets reverted by a new release - it will just break the app again.
Trying the same for the main SQL did not solve the problem there.
Also I posted a message '[IBO] Unwanted trimming of data' some time ago and had no response.
I see both these issues as fundamental simple data handling facilities that just don't work properly and as such should be high up on the priority list.
Sorry to be pain - could you reconsider?
Regards
Paul
I dont beleive the situation is as straight forward as you suggest. I have the same data type (examples with integer and char(1)) and the problem still occurs. I've aslo tried casting each side of the equality to no effect.
Setting FCombineDuplicateParams to False in IBA_UpdateSQL line 210 solves the problem for DeleteSQL. However I dont like this sort of change to the source because I wont see an error if it gets reverted by a new release - it will just break the app again.
Trying the same for the main SQL did not solve the problem there.
Also I posted a message '[IBO] Unwanted trimming of data' some time ago and had no response.
I see both these issues as fundamental simple data handling facilities that just don't work properly and as such should be high up on the priority list.
Sorry to be pain - could you reconsider?
Regards
Paul
----- Original Message -----
From: "Jason Wharton" <jwharton@...>
To: <IBObjects@yahoogroups.com>
Sent: Thursday, August 07, 2003 3:58 AM
Subject: Re: [IBO] Another parameter example
> Yes, this is exactly correct. I can only combine parameters if their data
> type is able to be merged buffer-wise (so to speak). I really should clear
> up this potential ambiguity and either raise an exception or make it figure
> out how to reconsile differing data types.
>
> I've added this to my list of items to resolve in a future sub-release.
>
> Regards,
> Jason Wharton
>
> ----- Original Message -----
> From: "Paul Vinkenoog" <paul@...>
> To: <IBObjects@yahoogroups.com>
> Sent: Tuesday, August 05, 2003 7:37 AM
> Subject: Re: [IBO] Another parameter example
>
>
> > Hi Paul,
> >
> > > I remember parameter problems with the new FB versions but dont
> > > remember any resolution to the occurring twice problem. I can get
> > > round this particular one by rewriting it to dynamic SQL. However I
> > > use multiple parameter occurrence a lot and it really needs to be
> > > resolved.
> >
> > Maybe I have a clue after all! Look at what Markus Ostenried wrote as
> > a solution to another problem:
> >
> > select *
> > from customer
> > where (type = :paramtype) or (Cast('*' as VarChar(3)) = :paramtype)
> > Note that you need to cast your constant value to the same field type
> > that you have defined your column with. Otherwise IBO will create a
> > second parameter of type Char(1).
> >
> > As said: this was an unrelated problem, but the importance lies in
> > what he says about casts. If you have multiple occurences of a named
> > param, _and_ you cast, at every occurence, the field, constant, or
> > whatever you compare the param with, to the same datatype (unless it
> > already has that type explicitly), IBO creates only a single parameter
> > and your problem should be gone.
> >
> >
> > HTH,
> > Paul Vinkenoog
>
>
>
> ___________________________________________________________________________
> 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 !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
[Non-text portions of this message have been removed]