Re: [Firebird-devel] arithmetic exception, numeric overflow, or string truncation after change column datatype and select from older format view

Em 23/11/2016 11:54, Adriano dos Santos Fernandes escreveu: > On 23/11/2016 11:50, Alexandre Benson Smith wrote: >> Em 23/11/2016 11:37, Adriano dos Santos Fernandes escreveu: >>> And in my opinion problem of metadata changes and >>> unreliable/unpredictable behavi

Re: [Firebird-devel] arithmetic exception, numeric overflow, or string truncation after change column datatype and select from older format view

Em 23/11/2016 11:37, Adriano dos Santos Fernandes escreveu: > > And in my opinion problem of metadata changes and > unreliable/unpredictable behavior with concurrent sessions precedes this > one, otherwise deeper recompilation will be a big problem. Perhaps I missed your point. The case I

Re: [Firebird-devel] arithmetic exception, numeric overflow, or string truncation after change column datatype and select from older format view

Em 23/11/2016 11:08, Adriano dos Santos Fernandes escreveu: > On 23/11/2016 10:56, Alexandre Benson Smith wrote: >> create view v as select a from t; > When you use the base field directly, the view field uses the same domain. > > When you create an expression based on this

Re: [Firebird-devel] arithmetic exception, numeric overflow, or string truncation after change column datatype and select from older format view

Em 23/11/2016 08:10, Adriano dos Santos Fernandes escreveu: > On 23/11/2016 06:15, Roman Simakov wrote: >> 2016-11-23 2:26 GMT+03:00 Leyne, Sean : >>> I can't imagine how the engine could manage to keep the schema/object cache >>> and transaction context in sync or, in

[Firebird-devel] arithmetic exception, numeric overflow, or string truncation after change column datatype and select from older format view

Hi ! On previous versions of FB (2.1 and earlier) one could not change the column datatype if it has any dependencies (for example used on a view), you need to drop all the views and after that change the column datatype and recreate everything. Fortunatelly, on FB 2.5 we could change the

Re: [Firebird-devel] RFC: Tablespaces

Em 3/3/2016 04:04, Dmitry Yemanov escreveu: > 03.03.2016 09:48, Dmitry Yemanov wrote: >>> Blobs could be moved into separate tablespace. It could make backup of >>> "data" tablespace faster and smaller. We can even think about "offline" >>> tablespace. >> Really good idea. Maybe more important for

[Firebird-devel] Forced Writes Off x MaxUnflushedWrites x MaxUnflushedWriteTime

a better performance and with MaxUnflushedWrites = 1 each page are written with out reordering. I hope someone could explain me if that is the case and if not why there is a huge diference. TIA Alexandre Benson Smith THOR Software

Re: [Firebird-devel] Planning the post v3 development

Em 28/4/2014 18:21, Claudio Valderrama C. escreveu: -Original Message- From: Carlos H. Cantu [mailto:lis...@warmboot.com.br] Sent: Lunes, 28 de Abril de 2014 12:30 DY Thanks, but I seemed to explicitly state that plain wishlists don't DY count. It seems that I also didn't

Re: [Firebird-devel] How to? Coordinating transactions for multiple connections in single call

Sean, Em 1/4/2014 19:59, Leyne, Sean escreveu: All, Consider a large database (200GB, large tables with 450 Million rows) which is running on a kick-a** server with pool of enterprise SSDs for storage (more IOPS then Firebird could ever use), which I need to extract data from on a

[Firebird-devel] Direct System Table Update

no way to achieve using DDL) in 2.5 and what will be changed on 3.0 ? Thank you ! Alexandre Benson Smith -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application

Re: [Firebird-devel] RFC: non-expandable fields

Em 4/4/2013 22:53, Doug Chamberlin escreveu: So forget the previous discussion for a moment. Especially any parts about the best ways to implement replication and SELECT * problems. Without getting into the details of the use case, essentially the OP asked for a way to suppress the presence

[Firebird-devel] Optmizer vs IN (sub-select)

Hi ! It's known that Firebird transforms this kind of query: select TableA.Foo from TableA where TableA.Bar in (select TableB.Bar where X=Y) into: select TableA.Foo from TableA where exists (select * from TableB where where X=Y and TableB.Bar = TableA.Bar) This