Re: [Firebird-devel] Necessity of prepare in FB3

On 20.09.2016 18:35, Dimitry Sibiryakov wrote: > 20.09.2016 17:38, Martin Schreiber wrote: >> Additionally I prefer robust and simple solutions without guessing. > Then you have no choice but call prepare. > > With current API - yes, but we discuss possible API change.

Re: [Firebird-devel] Necessity of prepare in FB3

On 20.09.2016 18:32, Martin Schreiber wrote: > On Tuesday 20 September 2016 16:02:26 Alex Peshkoff wrote: >> On 20.09.2016 12:25, Martin Schreiber wrote: >>> On Tuesday 20 September 2016 10:21:54 Alex Peshkoff wrote: > A convenient solution of the dilemma would be if openCursor() would >

Re: [Firebird-devel] Necessity of prepare in FB3

On Tuesday 20 September 2016 16:02:26 Alex Peshkoff wrote: > On 20.09.2016 12:25, Martin Schreiber wrote: > > On Tuesday 20 September 2016 10:21:54 Alex Peshkoff wrote: > >>> A convenient solution of the dilemma would be if openCursor() would > >>> work with any SQL statement. > >>> It seems that

Re: [Firebird-devel] Necessity of prepare in FB3

On Tuesday 20 September 2016 17:35:46 Dimitry Sibiryakov wrote: > 20.09.2016 17:38, Martin Schreiber wrote: > > Additionally I prefer robust and simple solutions without guessing. > >Then you have no choice but call prepare. Again, no offence meant, with other DB's we have. Martin

Re: [Firebird-devel] Foreign key error even there should not be one (maybe, Weird problem in one database)

I've said I can provide the DB and needed data if it is kept secret :) -Tee- On Tue, Sep 20, 2016 at 3:55 PM, Vlad Khorsun wrote: > 19.09.2016 14:06, Tommi Prami wrote: > > Weird part was that I actually pumped the data to the empty database and > it behaved the

Re: [Firebird-devel] Necessity of prepare in FB3

On Tuesday 20 September 2016 16:09:35 Dimitry Sibiryakov wrote: > 20.09.2016 16:02, Alex Peshkoff wrote: > > API able to execute any > > statement kind without prior prepare is certainly useful. > >And this API already exists. It is *_immed_* family in ISC API and > IAttachment.execute() in

Re: [Firebird-devel] Necessity of prepare in FB3

20.09.2016 17:38, Martin Schreiber wrote: > Additionally I prefer robust and simple solutions without guessing. Then you have no choice but call prepare. -- WBR, SD. -- Firebird-Devel mailing list, web interface

Re: [Firebird-devel] Necessity of prepare in FB3

20.09.2016 17:53, Alex Peshkoff wrote: > we discuss possible API change. In this case you should consider a method that returns output IMessageMetadata and message buffer allocated in client library in response to SQL query and input message. -- WBR, SD.

Re: [Firebird-devel] Necessity of prepare in FB3

On Tuesday 20 September 2016 17:58:36 Dimitry Sibiryakov wrote: > 20.09.2016 17:53, Alex Peshkoff wrote: > > we discuss possible API change. > >In this case you should consider a method that returns output > IMessageMetadata and message buffer allocated in client library in response > to SQL

Re: [Firebird-devel] Necessity of prepare in FB3

On 18.09.2016 10:24, Martin Schreiber wrote: > Hi, > Please bear with me if I am completely wrong, I am a simple toolmaker and no > database specialist. > > MSEide+MSEgui includes a fork of the Free Pascal SQLdb framework. There users > provide arbitrary SQL-statements and MSEgui provides the

Re: [Firebird-devel] CNCT_user and CNCT_host

On 19.09.2016 21:05, Jiří Činčura wrote: >> things. But for os user name - no, not ok. > Can you elaborate? > I've already did it before ;) > Existing server code removes them from DPB, takes values loaded > earlier from connect packet and puts into DPB. Pay attention - _removes_. Does not

Re: [Firebird-devel] Necessity of prepare in FB3

On Tuesday 20 September 2016 10:21:54 Alex Peshkoff wrote: > > A convenient solution of the dilemma would be if openCursor() would work > > with any SQL statement. > > It seems that a part of that solution already works, calling openCursor() > > with " > > insert into TABLE1 (STR1) values

Re: [Firebird-devel] CNCT_user and CNCT_host

> Pay attention - _removes_. Does not matter was there something useful in > CNCT or not. OK, I missed that. I though it's like a merge of values. Thanks. -- Mgr. Jiří Činčura Independent IT Specialist --

Re: [Firebird-devel] CNCT_user and CNCT_host

On 20.09.2016 14:47, Jiří Činčura wrote: >> Pay attention - _removes_. Does not matter was there something useful in >> CNCT or not. > OK, I missed that. I though it's like a merge of values. Unfortunately not. Certainly that can be fixed for fb4 and later but clients should better work with

Re: [Firebird-devel] CNCT_user and CNCT_host

> Unfortunately not. Certainly that can be fixed for fb4 and later but Given you can count provider writers on one hand, I don't think it's necessary. Either one does it correctly or keep trying (a lot of what I do :)). -- Mgr. Jiří Činčura Independent IT Specialist

Re: [Firebird-devel] Foreign key error even there should not be one (maybe, Weird problem in one database)

19.09.2016 14:06, Tommi Prami wrote: > Weird part was that I actually pumped the data to the empty database and it > behaved the same. > > This is more than less puzzling. > > And the Backup and restore did not help,. which also, I think, should > recreate the indexes and so on... Without

Re: [Firebird-devel] Necessity of prepare in FB3

On 20.09.2016 12:25, Martin Schreiber wrote: > On Tuesday 20 September 2016 10:21:54 Alex Peshkoff wrote: >>> A convenient solution of the dilemma would be if openCursor() would work >>> with any SQL statement. >>> It seems that a part of that solution already works, calling openCursor() >>> with

Re: [Firebird-devel] Necessity of prepare in FB3

20.09.2016 16:02, Alex Peshkoff wrote: > API able to execute any > statement kind without prior prepare is certainly useful. And this API already exists. It is *_immed_* family in ISC API and IAttachment.execute() in OO one. If an user of API can guess types on input parameters, types of