Board index » delphi » Re: Is there a future for Borland in .NET?

2005-07-27 03:44:37 AM
delphi272
Brian Moelk writes:
other ADO.NET solution. With Ramesh's forthcoming changes to BDP in
DeXter, it scales better in almost all cases than other ADO.NET
solutions.
Again, if this is so important to you at this time, there is nothing
preventing you from providing your own solution.
However, it appears to me that nothing I say will satisfy you on this
subject, so I am done with it.
--
John Kaster blogs.borland.com/johnk
Features and bugs: qc.borland.com
Get source: cc.borland.com
If it is not here, it is not happening: ec.borland.com
 

Eric Grange writes:
--
John Kaster blogs.borland.com/johnk
Features and bugs: qc.borland.com
Get source: cc.borland.com
If it is not here, it is not happening: ec.borland.com
 

an *advantage* in this area. Choosing BDP directly affects the scalability
of the resulting application. For me, I would much rather do more work to
abstract ADO.NET to get the advantages of BDP (if I need to) if it will mean
a better product in the end for my customer.
at the context of the discussion. We're talking about BDS vis-a-vis VS.NET
and what they bring the table in the context of a competitive market.
Delphi 2005. Besides, it is not about satisfying me, John, it is about
satisfying the market.
Did Delphi 2005 sell well? Did it outsell Delphi 7? How about its return
rate? Can you provide some case studies or success stories from companies
that have chosen Delphi 2005 over VS.NET?
 

"Brian Moelk" <XXXX@XXXXX.COM>writes
wouldn't be willing to either use Robert Love's pooler, or roll your own
when using BDS? How is that a fair comparison?
 

everyone needs to, many corporations are happy targeting just SQL Server or
Oracle. ISV's sure, but AFIAK, that isn't Borland's target market.
OTOH, I don't know of many shops developing a non-trivial ASP.NET website
that don't need the scalability that db connection pooling enables.
Also, there are other disadvantages of using BDP to do the database
abstraction over rolling my own layer:
1) BDP doesn't address SQL dialect differences, it is only a partial
solution. IOW, there is some extra work that needs to be done there anyway.
2) BDP drivers are not available from the DB vendor directly (besides
NexusDB and some others that target the Delphi market; most all DB vendors
do provide an ADO.NET driver). So we basically have to rely on Borland to
produce a driver for the database we want to use *and* hope that the driver
is of good quality.
3) BDP is not documented so it makes it difficult for those DB vendors or
third-parties to support it even if they wanted to.
So put this in the context of risk-management, after all that is what
software is all about right?
 

"Brian Moelk" <XXXX@XXXXX.COM>writes
everyone in your market. What I will claim is that Borland has done this
very thing (allow for easy cross-DB development) since - well - forever. For
you to suddenly claim that this (very big) feature is somehow now irrelevant
is convenient for you to make your agrument, but it doesn't hold water.
released. You can either roll your own (you'd have to do that for vanilla
ADO.NET, too), buy commercial, or find something else. Or, you could use
StoredProcs/Functions/etc. Or, you could write queries to a LCD approach.
Ramesh has released some more docs, and John has mentioned that you can get
access to that info in the BTP program. So the point here is what?
from some questionable assumptions and come to an untenable conclusion.
 

experience, anyone is free to agree or disagree.
the whole point.
does it? Perhaps Borland could to *more* in future versions, not just
reimplement the same things over and over again.
Again, it is not about whether or not BDP is good, it is about why it is
*significantly* better than ADO.NET.
I know my experience has been less than pleasant.
It's been undocumented for so long and I doubt we'll see Oracle or IBM write
a BDP driver. When compared with ADO.NET it is clear that there are more
choices for drivers for ADO.NET than BDP.
only one aspect of software development.
the competitive market place. My main point is that I don't believe BDP is
a slam-dunk clear-cut competitive advantage. BDP's advantage is
*questionable. If other developers agree with my point, then it is not
The only conclusion that really matters is how Delphi 2005 addresses the
needs of developers and consequently its revenue numbers.
 

Sorry, premature send...
share my experiences.
 

Craig Stuntz [TeamB] writes:
AFAIK, some CPUs even have loadable instructions sets.
--
Rudy Velthuis [TeamB] rvelthuis.bei.t-online.de
"Raymond's Law of Software: Given a sufficiently large number of
eyeballs,
all bugs are shallow." -- Eric S. Raymond
 

Bob Dawson writes:
It is rather unimportant what the exact output of the compilers is.
Don't forget that many C compilers can also output x86 assembler
(source) code, which you can tweak manually, if you like. Calling
compilers like the current .NET compilers IMO only serves one purpose:
to devaluate them.
--
Rudy Velthuis [TeamB] rvelthuis.bei.t-online.de
"Ever notice that anyone going slower than you is an idiot, but anyone
going faster is a maniac?" -- George Carlin
 

Eric Grange writes:
others are still playing catch up.
--
Rudy Velthuis [TeamB] rvelthuis.bei.t-online.de
"Why yes-- a bulletproof vest." - James Rodges, {*word*190}er, on his final
request before the firing squad.
 

Eric Grange writes:
reduces the unit-like scope of private and protected to really strictly
private and protected, i.e. even other classes in the same unit can't
access them, (except descendants, in the case of protected, of course).
It is a pure language feature, and not bound to .NET at all.
--
Rudy Velthuis [TeamB] rvelthuis.bei.t-online.de
"Modern capitalism is not about free markets, it is about building
sufficient mass that the market gravitationally collapses around you."
-- Alisdair Meredith, borland.public.off-topic newsgroup
 

Rudy Velthuis [TeamB] writes:
devalute them.
--
Rudy Velthuis [TeamB] rvelthuis.bei.t-online.de
"You're about as useful as a one-legged man at an arse kicking
contest." -- Rowan Atkinson.
 

Some Java/.NET interoperability solutions which use custom channels and
sinks (such as Borland Janeva and JNBridgePro) will not be compatible
with Indigo/Longhorn:
"Anyone who's built custom .NET Remoting extensions, however, such as
channels and sinks, will find that this code won't port to the new
world." - David Chappell [ Introducing Indigo: An Early Look
msdn.microsoft.com/webservices/default.aspx
]
However, I would like to introduce J-Integra Espresso, which is a true
CORBA solution for the Microsoft .NET framework without using custom
channels and sinks. This Object Request Broker (ORB) has been written
in C# and connects Java and CORBA with the .NET world. J-Integra
Espresso has been developed entirely as managed code - C# - and can
therefore be accessed by all .NET languages (C#, ASP.NET, etc...).
J-Integra Espresso is a bi-directional interoperability tool which
supports ".NET to Java", "Java to .NET", ".NET to CORBA" and "CORBA to
.NET".
For a free evaluation, please visit j-integra.intrinsyc.com/
Regards,
Raymond HE
Intrinsyc Software International, Inc.
J-Integra Interoperability Solutions
j-integra.intrinsyc.com/
When Web Services are not enough
 

XXXX@XXXXX.COM writes:
true. JNBridgePro is fully compatible with Longhorn/Vista, and will
work with programs that use Indigo.
Regards,
Wayne Citrin
JNBridge, LLC
www.jnbridge.com