Question is on Google + page
https://plus.google.com/b/111558763769231855886/+AchimKalwa/posts/8Pw5p9462Te?cfem=1
I guess it's a lot simpler now to apply the patch if we drop support
for windowsxp in firebird 3.x
--
Inf
-=| marius adrian popa, 29.07.2014 11:35:11 +0300 |=-
> Question is on Google + page
>
> https://plus.google.com/b/111558763769231855886/+AchimKalwa/posts/8Pw5p9462Te?cfem=1
>
> I guess it's a lot simpler now to apply the patch if we drop support
> for windowsxp in firebird 3.x
In this line of
On 07/28/14 20:12, Adriano dos Santos Fernandes wrote:
> On 28/07/2014 12:54, Tom Coleman wrote:
>> Every young developer knows Java and JDBC,
> Young developer should stay far from C++.
Yes and know. Not sure about South America, but in Russia (I did not
check myself, but trust people who sai
ROUND internal function
---
Key: CORE-4502
URL: http://tracker.firebirdsql.org/browse/CORE-4502
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 2.5.3
Environment: WINDOWS
Hi,
It is not the round function, but the calculation (25*75/197). Since all
arguments are integers, the result will also an integer (SQL convention).
Try: 25.0*75.0/197.0
Kind regards,
Robert
-Oorspronkelijk bericht-
From: Hugues Van Landeghem (JIRA)
Sent: Tuesday, July 29, 2014 1:50
Hi!
Our ALTER PACKAGE always destroys the package body, i.e., routines not
listed in the new package, BLR of listed routines, and the package body
source.
This request "as is" is not appropriate for me, but I tend to agree it's
bad to lose the package body source.
But if we maintain it and someo
It's good to have a core user base, but what is the trend?
I just spoke with a company that for a number of reasons would like to move
some 800 systems off of Delphi.
What language are they considering? Java. Their choice for database access?
JDBC. Why? Flexibility .
JDBC allows them
29.07.2014 18:14, Tom Coleman wrote:
> I just spoke with a company that for a number of reasons would like to move
> some 800
> systems off of Delphi.
Could you name some of these reasons?
--
WBR, SD.
--
Infragis
Title: Re: [Firebird-devel] New Interface
And what holds them from using Firebird, no matter what decision is made about the API?
Afaik, we already have a good JDBC driver.
I'll not discuss what language is better, since such discussions are useless and endless. Firebird just need to provide way
On Jul 29, 2014, at 12:35 PM, Carlos H. Cantu wrote:
> And what holds them from using Firebird, no matter what decision is made
> about the API?
Good question. And what could be holding back everyone else?
See the chart in the reference I posted earlier in this thread.
The line from the movie
29.07.2014 18:49, Tom Coleman wrote:
> would like to move some 800 systems off of Delphi.
So, they invested into these systems, but now they are dropping all
it into
trash can and preparing to spend another to a new attempt. They are
either lousy
for money or...
> And wha
The Vulcan strategy, not completed, was:
1. Maintain existing API.
2. Move SQL handling into core engine
3. Support JDBC has the interface for the future. New functionality would
be in JDBC first and probably only JDBC.
4. Extend protocol to support native JDBC.
There are efficiencies to be
On 29-7-2014 13:46, Alex Peshkoff wrote:
> On 07/28/14 20:12, Adriano dos Santos Fernandes wrote:
>> On 28/07/2014 12:54, Tom Coleman wrote:
>>>Every young developer knows Java and JDBC,
>> Young developer should stay far from C++.
>
> Yes and know. Not sure about South America, but in Russia
On 29-7-2014 18:49, Tom Coleman wrote:
>> Re: [Firebird-devel] New Interface
>> And what holds them from using Firebird, no matter what decision is
>> made about the API?
>
> Good question. And what could be holding back everyone else?
>
> See the chart in the reference I posted earlier in this thr
On 29-7-2014 19:04, Dimitry Sibiryakov wrote:
> 29.07.2014 18:49, Tom Coleman wrote:
>> would like to move some 800 systems off of Delphi.
>
> So, they invested into these systems, but now they are dropping
> all it into
> trash can and preparing to spend another to a new att
On 29-7-2014 19:20, Mark Rotteveel wrote:
> You'll find that a lot of JDBC drivers are a so-called Type 4 driver
> (pure Java), and some also provide a Type 2 (Java + native dependency)
> driver. Most users prefer a Type 4 because it doesn't require the hassle
> of correctly loading native dependen
29.07.2014 19:21, Mark Rotteveel wrote:
> Dmitry, I don't think this contributes to the discussion.
I asked a question about reasons to get off from Delphi and got no answer.
Can I a
right to be pissed off a little?..
--
WBR, SD.
-
When I mentioned that Oracle probably layered JDBC on OCI I was thinking about
the database side. I think everyone would prefer a Type 4 driver on the client
side.
Do you know if Oracle JDBC uses the OCI wire protocol? My guess would be that
it does.
(And "JDBC-like" it is from now on).
Be
On 29-7-2014 19:32, Dimitry Sibiryakov wrote:
> 29.07.2014 19:21, Mark Rotteveel wrote:
>> Dmitry, I don't think this contributes to the discussion.
>
> I asked a question about reasons to get off from Delphi and got no
> answer. Can I a
> right to be pissed off a little?..
Actually, no. Tom
On 29-7-2014 19:38, Tom Coleman wrote:
>
> When I mentioned that Oracle probably layered JDBC on OCI I was thinking
> about the database side. I think everyone would prefer a Type 4 driver
> on the client side.
>
> Do you know if Oracle JDBC uses the OCI wire protocol? My guess would
> be that it
A lot of it has to do with available maintenance skills [ie it's a
management issue - not just technical].
If you need to maintain for business reasons and your staff are saying "
don't want to maintain that..." then it makes sense to move - same argument
as jdbc-like-api - thats where the 'future'
Sorry, I missed your question. I didn't mean to ignore it.
Actually, $ is a big part of the decision. (Read "Linux is free").
Another is flexibility. (Read "Write once, Run anywhere").
Progressive companies are always reevaluating value per dollar or colloquially,
"bang for the buck".
On
So there you go.
The OCI wire protocol must be "good and complete" to be able to facilitate the
layering of additional interfaces.
Good luck getting any ideas from it without analyzing TCP packets, but if
anyone would like some ideas the TDS wire protocol used by MS SQLServer (#3)
and Sybas
Hi,
I understand the dilemma. I think it is inherent in having separate
statements for defining header (interface) and body (implementation). This
was probably done to be compatible with other sql databases??
But anyway, it is too late now to change this concept;)
If a new field with the old pac
This is a key point. The "real" API is the application protocol - the
rest is just language bindings. You need to start with a basic 'C' style
lowest common denominator binding and then add "better" ones, whether
that's C++, JDBC or whatever, and whether they use the basic API or go
direct to the w
ISQL command SHOW USERS display only me
---
Key: CORE-4503
URL: http://tracker.firebirdsql.org/browse/CORE-4503
Project: Firebird Core
Issue Type: Bug
Components: ISQL
Affects Versions: 3.0 A
26 matches
Mail list logo
