28.07.2014 22:48, Dalton Calford wrote:
>
> That is not exactly true. With Schema's, on DB2 and Oracle at least,
> not sure about other platforms, you can specify a default schema, either
> publicly or by user/connection.
Correct. Legacy apps will keep working as long as you don't reference
non
Hi Dmitry
On 28 July 2014 14:39, Dmitry Yemanov 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
> libraries.
>
>
Tha
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.
--
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: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 curre
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 - htt
So, let me understand this.
(a) the plan is to block/remove access to the system tables
(b) functionality will not be added until it is in the sql standard, even
though we are not implementing everything that is currently in that
standard as some of it does not make sense or no one wants to do it.
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, e
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
--
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, Silico
Has any work been performed on implementing schema/synonyms/larger object
identifiers?
On 28 July 2014 12:45, Adriano dos Santos Fernandes
wrote:
> 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
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 poss
that is isql only - try it in any other tool.
On 28 July 2014 12:12, Adriano dos Santos Fernandes
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?
>
>
> Adriano
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?
Adriano
--
Infragistics Professional
Build stunning Wi
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" h
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 a
On 07/28/14 16:12, Alex Peshkoff wrote:
> If we decide that having JDBC as a main firebird interface is a good
> idea as a possible solution not (almost not) delaying FB3 release may be
> used the following. Logically what FB3 interface does is very close to
> JDBC. We can rename interfaces in Pro
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 v
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
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 name IS {'txt'|NULL};
COMMENT ON COLUMN table_or_view_name.field_name IS {'txt'|NULL};
COMMENT ON {PROCEDURE | FUNCTION} [ .] name
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 t
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 p
> On Jul 28, 2014, at 6:23 AM, Alex Peshkoff 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 appl
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
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
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 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 feat
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/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
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 be
30 matches
Mail list logo
