On 07/25/14 18:53, Mark Rotteveel wrote:
The separation between Statement and PreparedStatement (and
CallableStatement) in JDBC may seem like overkill, but if you are
executing statements without parameters and you are only executing them
once, it is overhead to have to prepare a query
On 07/24/14 18:05, Adriano dos Santos Fernandes wrote:
On 24/07/2014 10:59, Alex Peshkoff wrote:
Also ugly.
I would better like to support setCursorName(NULL) in order to emulate
old API.
Fine for me.
One more problem - what to do if you use IAttachment::openCursor() and
after it want to
I'm pleased to announce new version of .NET provider. You can read more at
http://blog.cincura.net/233471-ado-net-provider-4-5-0-0-for-firebird-is-ready/ .
--
Mgr. Jiri Cincura
Independent IT Specialist
--
Infragistics
On 07/25/14 18:43, Jim Starkey wrote:
If an interface is incompatible, existing applications have to be recoded.
If they need to be recoded, there isn't any real purpose to retaining an
interface style.
For existing applications we support legacy ISC interface. Certainly,
when new features
28.07.2014 11:23, Alex Peshkoff wrote:
For existing applications we support legacy ISC interface. Certainly,
when new features (like schema) will be added, they will be accessible
only from new one.
I wouldn't be so sure in this. ISC API was well designed and is easily
expandable.
Every
On 28/07/2014 04:52, Alex Peshkoff wrote:
On 07/24/14 18:05, Adriano dos Santos Fernandes wrote:
On 24/07/2014 10:59, Alex Peshkoff wrote:
Also ugly.
I would better like to support setCursorName(NULL) in order to emulate
old API.
Fine for me.
One more problem - what to do if you use
On 07/28/14 14:37, Adriano dos Santos Fernandes wrote:
On 28/07/2014 04:52, Alex Peshkoff wrote:
On 07/24/14 18:05, Adriano dos Santos Fernandes wrote:
On 24/07/2014 10:59, Alex Peshkoff wrote:
Also ugly.
I would better like to support setCursorName(NULL) in order to emulate
old API.
Fine
On Jul 28, 2014, at 6:23 AM, Alex Peshkoff peshk...@mail.ru wrote:
On 07/25/14 18:43, Jim Starkey wrote:
If an interface is incompatible, existing applications have to be recoded.
If they need to be recoded, there isn't any real purpose to retaining an
interface style.
For existing
On 07/28/14 15:00, Jim Starkey wrote:
First of all I must say that the troubles I've mentioned with
prepareStatement() are vulcan-specific. I've read your arguments, they
match my mind re. that issue, all the problem was due to some
misunderstanding and attempt to reference JDBC in incomplete
28.07.2014 14:12, Alex Peshkoff wrote:
But that's not what only I decide. An argument that for a person who
used to work with ISC API for a long time change to current fb3 API is
simpler than to JDBC one remains present.
As I said once, it is simpler to adapt ISC API for new FB features
In ddl.txt wrote
...
4) Allow comments in database objects.
(Claudio Valderrama C.)
Proposed syntax for testing:
COMMENT ON DATABASE IS {'txt'|NULL};
COMMENT ON basic_type name IS {'txt'|NULL};
COMMENT ON COLUMN table_or_view_name.field_name IS {'txt'|NULL};
COMMENT ON {PROCEDURE |
On 28/07/2014 10:58, Simonov Denis wrote:
In ddl.txt wrote
Ok. Thanks.
Adriano
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a
I wonder - is there anyway via sql to get access to the comments other than
via the system tables?
Shouldn't there be something like a DESCRIBE statement as a corollary to
COMMENT ON?
A DESCRIBE DDL or DESCRIBE DEPENDENCIES giving a standard tool via sql for
database developers would be perfect
DEC is a great example of why technical people should never be allowed to have
the final say in business decisions. There are others. Anyone else besides
Jim remember Wang Laboratories?
(I suppose the same could be said for letting the suits have the final say,
but that's an argument for
On 28/07/2014 12:54, Tom Coleman wrote:
DEC is a great example of why technical people should never be allowed
to have the final say in business decisions. There are others.
Anyone else besides Jim remember Wang Laboratories?
(I suppose the same could be said for letting the suits have the
that is isql only - try it in any other tool.
On 28 July 2014 12:12, Adriano dos Santos Fernandes adrian...@gmail.com
wrote:
On 28/07/2014 12:08, Dalton Calford wrote:
I wonder - is there anyway via sql to get access to the comments other
than via the system tables?
show comments?
On 28/07/2014 13:40, Dalton Calford wrote:
that is isql only - try it in any other tool.
Show me where is such type of command in the SQL standard, or I will be
against it. Not because I think everything should be in the standard,
but because I think it would be artificial.
The only thing
Excuse me, sir, but the Ken Olson and Gordon Bell who built the second
largest computer company in the world were engineers. The jerk Palmer, who
wrecked it, was a business type.
There's a great deal more to it, but big computer companies all became
dinosaurs. Wang, Prime, DG, DEC, Sun, Silicon
28.07.2014 20:57, Dalton Calford wrote:
Has any work been performed on implementing schema/synonyms/larger
object identifiers?
Nope, as far as I'm aware of. It was proposed for v4 but so far I don't
see anybody jumping in with lots of interest...
Dmitry
Title: Re: [Firebird-devel] New Interface
Jim makes a good point about JDBC accounting for probably 80+% of modern database access. Every young developer knows Java and JDBC, and the standard makes it easy for tool developers to support the database.
Due to legacy reasons (IB, Borland,
Title: Re: [Firebird-devel] COMMENT ON docs
So, let me understand this.
(a) the plan is to block/remove access to the system tables
Afaiu, you will not be able to change the system tables, but will still be able to access (read) them.
[]s
Carlos
http://www.firebirdnews.org
FireBase -
28.07.2014 20:20, Dalton Calford wrote:
So, let me understand this.
(a) the plan is to block/remove access to the system tables
Write access, not read.
(b) functionality will not be added until it is in the sql standard, even
though we are
not implementing everything that is currently
28.07.2014 22:20, Dalton Calford wrote:
So, let me understand this.
(a) the plan is to block/remove access to the system tables
Wrong, at least in the short term. Currently we're trying to block
*write* access to the system tables, no more than that.
(b) functionality will not be added
28.07.2014 20:39, Dmitry Yemanov wrote:
I don't
think you can have/use schemas without recompiling all those thousands
of existing applications and/or their underlying database connectivity
libraries.
It depends on what you have on mind saying can use schemas.
--
WBR, SD.
Hi Dmitry
On 28 July 2014 14:39, Dmitry Yemanov firebi...@yandex.ru wrote:
Yes, it's actively developed. No, it doesn't support schemas. I don't
think you can have/use schemas without recompiling all those thousands
of existing applications and/or their underlying database connectivity
25 matches
Mail list logo
