Tony Gravagno wrote:

Okay, I understand that. But a little information from them would be
welcome. I have no problem with them saying "ODBC is not the way to go
with VS2005. You need our PDP.NET product. ODBC is old hat." I'm okay
with that, because it tells me where I stand. I now know the direction I
must go - to a .NET compliant solution. But not saying ANYTHING!

Besides, if what you say is true (that ODBC is not the way to go) then
why should they make me "prove" that it doesn't work. Simple courtesy
(and business sense) would dictate that they say "don't bother". If they
know it's not right, tell me so!

I'd much rather hear a "no" than nothing. A "no" at least gives me
direction.

Bill,

Well, good company, pleasant topic to discuss and vodka that time helped
much. This thread in fact doesn't bring much fun for me either.

Nick

"Bill H" <notme (AT) bogus (DOT) com> wrote

Let's assume that ODBC is certified for this environment just like any
other component. Since no one has officially told RD that something
is wrong, how do they know it's not working? How can they issue a
statement unless they are aware that there is something to issue a
statement about? How do we know that there isn't a config setting or
registry entry or some other well known tweak that people here missed
that is required for VS 2005?

Again the problem is that no one to my knowlege has reported anything
that RD can act on with a code change or some announcement of
incompatibility. Apparently no one cares enough about this to pick up
the phone and actually request assistance. Who defines the priorities
here? You guys do! And if you say it's not a priority then it's not.

And if you want your VS2005 to work you had better get this
information flowing quick because the VS2005 BETA (which people are
running, but read again "BETA") is pretty much closed as they prepare
for production. The RD ODBC code is years old and the VS2005 BETA is
about a year old, and only now are we arguing about incompatibility?

Last note, MV ODBC with .NET isn't just an RD issue. One of my
Universe clients has had issues for months with ODBC. They then
changed to OLEDB. When that wouldn't work they switched to mv.NET.
Even when IBM is aware of the problems they still can't make their
Pick DBMS completely look like a Relational platform to SQL without
hiccups. You have to go with what works.

T

SH <shamada (AT) prupipe (DOT) com> wrote:

Tony,

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

If a vendor claims his software is certified for, let say, ODBC/OLE
DB/ADO.NET common standards complience, it's his duty to maintain, meant,
test/debug/QA this software.

If they are ineterested in supporting standards, they need to go ahead of
their customers in facing issues.

Can't agree with this. These days the (most successful) vendors are the ones
who invent features and promote them to customers in such a way that
customers start believing that they can't live anymore without features not
known to them just a minute before they knew that such things exist. I doubt
that new features in the VS 2005 specs were compiled by Microsoft on the
basis of "official" customers support requests.

Nick

"Nikolai Lukin" <nvlukin (AT) gran-service (DOT) ru> wrote:
OK Nick, please point to anything that RD has published that states
the D3 ODBC client or server are ADO.NET compliant. I can't find any
reference to ODBC from RD since the release of 2.0.27 in 2001. RD's
only claim to VS 2005 compliance that I can find is a big announcement
that PDP.NET was certified for Whidbey - and since VS 2005 is
"supposed to be" backward compatible, all that means is they
successfully recompiled their assemblies. Hey, Marketing is what it
is... PDP.NET is RD's strategic business replacement for the D3 ODBC
class library. To my knowledge they haven't made any significant
changes to it in years, and my guess is that this has as much to do
with their business agenda as it does the technical difficulties of
maintaining those components. I might have missed some notification
of FCL 2.0 compliance but I doubt that we'll ever see one.


It's not whether THEY are interested in supporting standards. It's
whether or not YOU their client base is interested. Since no one has
told them that this is important then why should it be important to
them. They're in business to make money by selling software - how is
that business model supported by the altruistic endeavor to support
technology that the client base isn't using?


Well, there are a multitude of brilliant features in D3 that most RD
VARs will never know about because they continue to develop in
R83-compatible mode. When the market has already established that
position how can you expect a company to invest any more energy into
forward thinking? Do we expect them to keep pumping features into
these products that only one or two people will use? I'm sorry, but
"build it and they will come" simply doesn't work in this market.

To come back on that a second - I believe RD has never properly
marketed their product features properly, so how can they expect
people to use the features? The documentation (like Enhancements and
Resolutions docs) doesn't really explain all the great stuff that
Engineering puts into the products, so you guys never use the
features. But that's not all cause and effect - most of the features
that ARE well documented aren't used anyway, so there isn't much
motivation to provide detailed documentation. And if no one uses the
features then of course some one person will stumble on a bug only
years after the feature has been added to the product - but by then
the low priority has been established, no one uses the feature so why
fix it? It's a viscious circle that leads to exactly where we are -
and a constant source of angst on my part as you've seen here for many
years.

As always, I don't always agree with the policies in place. All I can
do is explain the way things work, not in a perfect world but in the
world that we live in, and it's up to you to either work with the
system as it is or find different tools and providers. After all of
this rhetoric I still haven't heard one person say that an issue has
been reported to RD, bringing me back to "if they don't know about a
problem, how can they fix it?"

I maintain that if something is important to you that you need to
communicate with your vendor. VARs need to elicit future requirements
from end-users, then translate that into business requests for your
upline providers. If your upline doesn't listen then you have
business decisions to make, but so far I don't see those communication
channels open in the first place.

T

SH wrote:

Who'd of thunk it?