Hi,

In D5, it's possible to use TAdoQuery, say aQry,  to ALTER stored 
procedure.having input parameters. In such a case within the SQL script 
(i.e. aQry.SQL.Text) calls of input parameters should be prefixed with 
*double* colon.

This approach seems to be broken in XE6; the test we did, in D5 and XE6, 
used the same IB Server 2009 and the same IBProvider.

Any hint will be very appreciated.
JK

Thank you, Jeff,

Indeed, my aQry.ParamCheck was True (default) but when I forced it to False 
nothing changed; I get the same
"SQL error code = -104
Token unknown - line xx char yy :"
The indicated (faulty) char is the first colon of the double-colon prefixing 
an SP parameter.

BTW, on D5 system the same code runs w/o error and with the default 
ParamCheck=True.
JK

"Jeff Overcash (TeamB)"  wrote in message 
news:711226@forums.embarcadero.com...
> Jacek Komorowski wrote:
>> Quinn,
>>
>>>> Does this work for you?
>> It *can not* work for us because the project in question is very big and
>> more than heavily depending on ADO. Many years ago we have chosen ADO not
>> because of its beauty but because it seemed the last possible to be
>> deprecated at Borland.
>>
>> I can not imagine that your current ADO interface "prevents" 
>> programatical
>> execution of such fundamental SQL script as ALTER PROCEDURE having input
>> parameters. It's crucial for programatical creation of database.
>>
>> I hope you will do your best, please.
>> JK
>>
>>
> Sounds like you have ParamCheck true (default).  ParamCheck should be off 
> even
> back in the D5 days when executing SQL.  ParamCheck on causes : to 
> be
> replaced by a ? before being sent to the server.  ParamCheck false means 
> send
> the SQL exactly as written to the server, not preprocessing.  :: would be 
> an
> error in that situation.  Just a single :.
>
> -- 
> Jeff Overcash (TeamB)
>       (Please do not email me directly unless  asked. Thank You)
> And so I patrol in the valley of the shadow of the tricolor
> I must fear evil. For I am but mortal and mortals can only die.
> Asking questions, pleading answers from the nameless
> faceless watchers that stalk the carpeted  corridors of Whitehall.
>              (Fish)

Jacek Komorowski wrote:
> Quinn,
> 
>>> Does this work for you?
> It *can not* work for us because the project in question is very big and 
> more than heavily depending on ADO. Many years ago we have chosen ADO not 
> because of its beauty but because it seemed the last possible to be 
> deprecated at Borland.
> 
> I can not imagine that your current ADO interface "prevents" programatical 
> execution of such fundamental SQL script as ALTER PROCEDURE having input 
> parameters. It's crucial for programatical creation of database.
> 
> I hope you will do your best, please.
> JK
> 
> 
> "quinn wildman"  wrote in message 
> news:711177@forums.embarcadero.com...
>> We've not updated ADO in a really long time, but certainly have since
>> Delphi 5. While ADO is certainly a legitimate interface to connect to
>> InterBase, it's rarely the choice because there are better alternatives.
>> So, before any potential investigation is done with ADO, I'd like to
>> suggest you look at IBX or FireDAC instead. Does this work for you?

Sounds like you have ParamCheck true (default).  ParamCheck should be off even 
back in the D5 days when executing SQL.  ParamCheck on causes : to be 
replaced by a ? before being sent to the server.  ParamCheck false means send 
the SQL exactly as written to the server, not preprocessing.  :: would be an 
error in that situation.  Just a single :.

-- 
Jeff Overcash (TeamB)
       (Please do not email me directly unless  asked. Thank You)
And so I patrol in the valley of the shadow of the tricolor
I must fear evil. For I am but mortal and mortals can only die.
Asking questions, pleading answers from the nameless
faceless watchers that stalk the carpeted  corridors of Whitehall.
              (Fish)

Quinn,

>>Does this work for you?
It *can not* work for us because the project in question is very big and 
more than heavily depending on ADO. Many years ago we have chosen ADO not 
because of its beauty but because it seemed the last possible to be 
deprecated at Borland.

I can not imagine that your current ADO interface "prevents" programatical 
execution of such fundamental SQL script as ALTER PROCEDURE having input 
parameters. It's crucial for programatical creation of database.

I hope you will do your best, please.
JK


"quinn wildman"  wrote in message 
news:711177@forums.embarcadero.com...
> We've not updated ADO in a really long time, but certainly have since
> Delphi 5. While ADO is certainly a legitimate interface to connect to
> InterBase, it's rarely the choice because there are better alternatives.
> So, before any potential investigation is done with ADO, I'd like to
> suggest you look at IBX or FireDAC instead. Does this work for you?

We've not updated ADO in a really long time, but certainly have since 
Delphi 5. While ADO is certainly a legitimate interface to connect to 
InterBase, it's rarely the choice because there are better alternatives. 
So, before any potential investigation is done with ADO, I'd like to 
suggest you look at IBX or FireDAC instead. Does this work for you?

Jacek Komorowski wrote:
> Hi,
>
> In D5, it's possible to use TAdoQuery, say aQry,  to ALTER stored
> procedure.having input parameters. In such a case within the SQL script
> (i.e. aQry.SQL.Text) calls of input parameters should be prefixed with
> *double* colon.
>
> This approach seems to be broken in XE6; the test we did, in D5 and XE6,
> used the same IB Server 2009 and the same IBProvider.
>
> Any hint will be very appreciated.
> JK
>