[comp.databases.ms-sqlserver removed]

Wow, five days later Volker is still scratching his head about this, I
though this thread was dead long ago.

> > Your argument, as usual, is that I should just believe you, not
> > because you have explained yourself, but just because you *know*.

> Wrong. My argument is that I've taken your "suggestion" long ago.

Huh? If you have taken my suggestion, then why did respond to my
suggestions? Did you imagine, that although I was not responding to
you, somehow It was you I was talking about? As usual, you make no
sence.
 
> > My orignal comments still hold true, the right to sue is cold comfort,
> > the right to pick up your pieces and try somewhere else, keeping your
> > application in tact as much as possible, is better.

> It simply doesn't work. Try it sometime.

'Simply doesn't work' -- an unsubstantantiated out of hand dismissal,
which is, as anybody with clue knows, a fallacy.

'Try it sometime' -- Another attempt to portray yourself as having
greater experience, another fallacy.

Well, what more can we expect from Volker, the human fallacy?

> > > > > at least, the right to cancel the
> > > > > contract which hurts them way more
> > > >
> > > > How can you cancel the contract when your entire application is
> > > > dependanton there product? Can you afford to throw away your
> > > > application too?
>  
> > > See my other posting. Compared to changing the application (replacing
> > > it with another), changing the underlying database is easy.
> >
> > Even easier if you have abstracted your data access with a simple
> > function, and then used that function throught your application. I
> > have no idea why you find this so hard to believe.

> As I said before, "a simple function" doesn't do it because
> there are lots of other things specific to a database so that
> the porting to another database won't be significantly eased.

The specific proprietary bindings can be wrapped in a simple function.
Additional functions can be used to issolate proprietry features.

> And, I'm trying to convey this too, there's no need to ease it
> much more because it's not much trouble anyway.

Thanks for all your effort Volker, but I will continue putting any
proprietary bindings my own functions, and use those functions through
out my application, rather than have proprietary binding through out
my application, and I will continue to recomend that others do the
same, you do whatever you want though.

> > And for what purposes are you bringing up changing the application?
> > How is this comparison relevent? I am trying to explain how to protect
> > your investment in your application; to change it as little as
> > possible.

> I'm trying to tell you that whatever API I'm using, the application
> is protected enough against any change.

The question was: Why are you bringing up changing the application as
if it was an argument _against_ my suggestions, since my suggestions
help protect your applications. Please try to follow.

> > You make so little sence I wonder what is motivating you to carry on.

> Whatever.

I see. So so simple having nothing better to do? This will be my last
response in this thread then. At least outside the PHP newsgroups.

> > Abstraction of your database access is a good idea. Why are you so
> > hell bent to dispute this.

> It depends on how much performance it costs.

Funny, that's what I said. Usualy however, performance concerns are
not terribly significant and the abstraction can be kept very light
weight.

> > Why would anybody do work fo you for free? Are you a charity of some
> > sort?

> You started out by saying that maintenance contracts are evil things
> devised by the big companies to suck their customers dry.

No, closed source licence agreements are so devised. Maintenence
contracts are perfectly fine.

> Now suddenly
> it's obvious that I pay for changes/fixes and that this is a cost factor when
> deciding about an investment.

You pay for labour, yes, why would this not be obvious?

> That it doesn't make sense to turn me or our company into database 
> specialists.

I don't know what makes sence for your company, but it should be
obvious to you that my advice is not directed at your company
specificaly, and also, my advice is not to become database
specialists, but rather to not make your own application, especially
if it is a 'high end commercial application' as described in the post
I was responding to, exclusively dependend on a third party.

> That therefore access to the source code doesn't make sense to us.

Access to the source code gives you the freedom to swith 'database
specialists' even if you never touch the code yourself.

It also means you never have to stop using the product simply because
the vendor wants to sell you a new one if the product continues to
meet your needs, since with source, you can recompile for for a new
cpu, a new os, or when new security updates are available for the
libraries it depends on.

With source, you have the assurance that the product is yours for
keeps, just like your own code, without source, you have no such
assurance.

> > If it did come to a dispute, they could not have supported there own
> > application, they where exclusively dependendant on an outside firm.

> You are talking ifs here. The contract was as it was and they were right.

Yet my advice is for the future, not the past, I see the example given
as cautionary tale because of the 'ifs'.

> > Because he had no right to go elsewhere if the vendor failed to
> > deliver.

> And in what way is that different if mysql AB goes bust and fails to deliver?

You still have the source code.

> > Relevence? What insurance is provided in the case here?
> > Fire insurance you can buy, I have never heard of application
> > obsoletion insurance.

> Maintenance is insurance to the database vendor. For a fixed price (or 
> whatever) the vendor agrees to do maitenance work.

Yet the vendor gaurantees nothing.

> The database vendor obviously
> balances maintenance costs and development costs, trying to minimize both.

The vendor only tries to maximize profits.

> > The original point being, you can not recoup your own investment, just
> > the purchace price.

> Yes. The same is with open source software. At least if you place a 
> reasonable
> limit on the costs to maintain the open source software yourself. (Reasonable
> meaning it should cost less than a migration to another supported product.)

You do not need to, just like if you design a curcuit with a
proprietary conector or a standard one, the former is expensive and
only comes from one comany, the later is cheap and comes from many.
Unless you really need the former, you would always chose the later.
In neither case are you required to manufacture connectors.

> > > No, they wouldn't, because first they would have to understand the code.
> >
> > If they where a credible provider of support and development for this
> > particular product, they would certainly understand the code.

> Well, looks like the only credible supporter of mysql is mysql ab.

There are as many as the market will bear, since there is no
artificial thing, like closed source, keeping competition away.

Since the Market is growing rather fast, and big names like SAP are
promoting it, I see no reason to worry about a lack of support for
MySQL.

> > > > Were do you get this idea? You can contract many companies, large and
> > > > small, to support your open source product, the difference being that
> > > > you can hire another when when they fail, because you have a right to
> > > > the source code, where as you have no recource when the provider has
> > > > all the rights.
>  
> > > Like, suse and redhat, each doing their own distributions?
> >
> > Huh? No, like a competent development comany providing devlopment
> > services, exactly like Oracle does, but without trapping you into a
> > sole source situation.

> And right now it works because they all more or less follow redhat.

What? Who follows Red Hat? What does this have to do with companies
providing development services? What are you blathering about?

> Nevertheless, each commercial software gets certified for single platforms,
> therefore you are still tied to a single distribution, or the supported
> subset.

Different products have different cross platform stragies, the good
ones try and support the widest number of platforms, almost all
serious database software supports Linux now, including Oracle and
Sybase. But in anycase, I have no idea how this relates to anything we
are actualy discussing. Must be something funny in the drinking water
in your parts.

> > > Could you provide a link where IBM actually provides support
> > > for mysql? The only thing I have found is them bragging that  MySQL AB
> > > (fully) supports the AIX port, not that IBM supports MySQL.
> >
> > Your question is yet another fallacy, since you are responding to a
> > general statement,

> So, who is the competitor for mysql ab?

Anyone who wants to be, as many as the market will bear, each
competeting for customers and compentent labour with each other to the
benifit of the consumer, simple economics.

Oracle has you trapped because no one else can compete with them,
since their source is closed. BUT EVEN STILL, I am not recomending you
never use Oracle, I am only recomending that abstraction is a good
idea, particularliy when you do not have source.

> > IBM Application development and systems integration
> > http://www-1.ibm.com/services/us/index.wss/it/bcs/a1000402

> Yes. Doesn't mention support or databases anywhere.

As I said, your question was a fallacy, since it was in responce to
the statement that many companies, including IBM, support open source
products, the statement did not say that IBM, specificaly, supports
MySQL, specificaly. Yet, if you wanted to, you could hire IBM to
support your MySQL implementation, if you had enough money, they would
be happy to take it. They do not promote themselves as such, and would
frankly be surprised to get such a contract, knowing that there are
cheaper alternatives and that MySQL users are not currently the
typical IBM consulting clients, however, with SAP behind MySQL AB,
this could soon change.

> > > I do get locked into a third party dependency, even if I can change
> > > the third party.
> >
> > If you can change it, you are not 'locked in.'

> So, if I can change the db from oracle to db2 I'm not locked in either.

That's right, you are only 'locked in' if you can not change.

> > All these question depend on the case, and have nothing to do with the
> > topic, if you have a right to the source you are safer that if you do
> > not, if you have abstracted your access you are safer still. What is
> > it you can not understand?

> That I am supposed to be safer with a bunch of code that, in the case
> I need it, is obsolete or takes time and expertise to get into.

If the code is a working part of your application, it is not obsolete,
however a closed source vendor can obsolete it on purpose to force you
to buy a new licence. And you need no expertise in it, since if your
product is popular, like say MySQL, the marker will attract lots of
competition for your business.

> > You have the *right* to use it and have it changed for ever and ever,
> > not only by the permission of some outside company.

> So what? The right to use it doesn't make me a programmer for that particular
> database.

If it's a working part of a production system, you do not need to be,

> It doesn't make anyone else (short of the original maintainers)
> a programmer for that particular database on short notice.

If it is a viable market, there will be programmers for it.

> It doesn't make
> the maintenance cheaper than the migration to a still supported database.

It may make migration uneccessary by allowing new entreprenuers to
support it. Competition among them will even make maintenance cheaper,
and, of course abstraction makes migration, when neccessary, also
cheaper.

All this in perfect line with my adivice, as stated in my original
posting, and as still unrefuted in anyway by you copious blather.

> And it definitely doesn't make my boss keep a bunch of abandoned code
> that we are the sole users of.

First, if the system is widely used the code would not be abandoned,
second, a closed source product is not less likely to be abandoned
that an open source one, third if it is abandoned then you are in
better shape if you do have the code.

> > > He's my slave because I pay him.
> >
> > No, he can simply ignore you if he decides the relationship is no
> > longer profitable for him. You can do nothing.

> I can stop paying maintenance and go somewhere else.

You must also stop using the software then, and bear the costs related
to that.

> > > Abstraction can make the job easier, you are right here, but then
> > > changing a database is not that hard too, as long as both are relational
> > > ones.
> >
> > That's all I'm saying, Abstraction is a good idea. I was giving some
> > simple, good advice. What are you saying?

> That "elegance" is more than "abstraction" and means different things
> to different people.

I have not attempted to define elegence for different people, only
given specific examples.

> And abstraction doesn't always make sense either

I never said anything *always* makes sence, all projects have their
own requirements, I have only given some general advice, good advice.

> > > Yes, I would. Because I'm not going to maintain my own database
> > > distribution.
> >
> > Nobody asked you to.

> But you always tell me how good it's supposed to be. Well, it is not.

No, I tell you that source gives you freedom to chose, but sadely, 
you have trouble understanding simple things. It's probably quite a
good idea for you to pay Oracle to think for you, in your case, I
withdraw my advice, however it still holds true for others, mor
compitent profesionals

> > You have the right to use the product and never
> > talk to the developer if you like. You don't need to change it to
> > enjoy the rights
> > that source code gives, that is the right to use the
> > product for ever, and even have it changed *if you need to*

> Oh, I've got the right to use oracle forever too. It's only what I
> want updates that I have to talk to them.

First of all, you do not have any such right, secondly, without
source, how you will compile it for your new CPU, or new OS, or to
link a security-updated library?

Oh never mind, just call Oracle support, you are obviously unskilled
labour.

Good luck to you.

> > My advice is to abstract when you have no source code, and perhaps
> > even then, I have repeated this many times and am not sure what you
> > are even disputing.

> Your advice. Abstraction means you won't need/use a distinguishing feature.

If you do not need to use it, yes, if you do, then //issolate its
use// in your code with a wrapper function.

> Therefore abstraction is to be decided on a case-to-case base just like
> any other thing.

Funny, that's exactly what I said, many times in this thread. Yet
abstarction is good advice, which is, as I've also said many times,
all I have offered.

> > Yes, that's why I am *recomending* abstraction. Are you just typing
> > compulsively at this point?

> No, I'm showing you the contradiction of your arguments.

No, all your showing is your inability to follow a simple arguments.

> If it's easy to change, the case for code rights disappears. Which way do
> you want it?

The 'case for code rights' does not disapear, but by abstarction,
becomes less important, since abstarction is another layer of
protection. This has been clear from my very first post in this
thread. Keeping your archices in self-contained, self-describing,
human-readable format was my third recomendation. If you have all
three, you are in the best shape if your application and/or data has a
long life span.

> > > It's different for databases.
> > > A) the customer quite often already has a database and expertise
> > >      maintaining it. He has an interest not to have another.
> >
> > Abstaction means your application can run for different clients with
> > different databases then. double plus good.

> But, and that's the point here, if every vendor provided its own patched
> mysql database the customer would be even more pissed off.

No one is recomending this, that is only your own red herring. The
customer prerers abstacation when it means that they can use there own
database, if they only use the database for your application, then
they see the database as a part of your application, and only want it
to work.

> Believe me, it's easier to say "we require oracle" that "we require you
> to run my oen hacked version of MyFavouriteOpenSourceDatabase.

Depends on the costumer and wether or not they want to bear of adding
Oracle to their environement.

> Are you trying to change thread from opensource to abstraction?

I am not trying to change 'the thread' -- I posted my recomendations,
which included abstractions, you are responding to them, therefore in
the discusion between you and I, it is my suggestions that are the
topic and my only intrest is in defending them, I have no other reason
to discuss anything with you.

> > However if your application is tied to one database, then the very
> > client you are describing is the very client that you will not get if
> > they use a different database from yours.

> We do have such an app here. The result is that it doesn't run well
> on *any* database.

As I said, there are bad applications, both abstracted and
unabstracted ones, your argument, is, as usual, a fallacy.

> > > B) the customer may  trust Larry ellison, or IBM more than me.
> >
> > But if they only sent there money to Lary because they purchaced your,
> > unabstracted application, they would be pissed off when it did not
> > work, and you blamed it on Larry.

> Ah, but I only blame it on larry if it's larrys fault.

And, if your forced your customer into Larry's arms, they will blame
you, not Larry.

> > > C) the customer may want a database that can do more than I could
> > >      implement or maintain, like incremental backups, logical/physical
> > >     standby databases or security.
> >
> > Exactly, so how are you going to accomplish this with your
> > unabstracted application? Do you even remember what side of this
> > debate you are on?

> I use a database that can do that and tell them to get the discount
> version if they don't need it. How do you going to accomplish
> that with an open source app where you are the only surviving
> supporter? Just to get back to the open source topic here.

I don't plan on being 'the only surviving supporter', yet another of
your fallacies, as the producs that I use are popular and their
popularity is growing, I also abstract my database access, so that if
this changes, I can change with the dominant trends.

(I wonder if you even know what a fallacy is, you use so so many of
them)

> > > Another case where it's different would, for instance be the OS.
> > > How much linux maintenance do you think you can provide,
> > > compared to redhat or suse? Is this really your corebusiness
> > > or area of expertise?
> >
> > Why do I have to?

> Why would you have to provide support for a database then?

I support my application and all the dependencies that I have forced
on the client by way of it. If my application fails because of a
dependency I have chosen for it, the customer will blame me.

> Remember you disputed that it's a good idea to let larry provide
> the oracle support.

Remember, it was limited to the situatuion where the customers only
dealt with Larry because of me. For the millionth time, please try to
follow.

> > Since I can hire one of a million support providers
> > for any OS,
> > however for OSes without source, they can't do much when
> > the problem is with the OS itself. Same with the database.

> So, how many have you under contract and how do your customers
> react to the news that they have to run your own linux distribution?

What on earth are you talking about? I do not need to run my own linux
distribution. You are a nutcase.

> > Again, my argument summerized for the millionth time: If you have no
> > source Abstract access for sure, and it's also a good idea to abstract
> > access even if you do. I'm baffled how you've turned this into such a
> > long conversation.

> In case you've already forgotten, the topic was open source, not abstraction.

I made a series of suggestions, including open source and abstraction,
you responded to my suggestions, therefore the topic is my suggestions
and your objections to them.

> In your case abstraction wouldn't have made sense because you won't ever
> need to change the database because you'd just carry on supporting it or
> buy the best (probably original) developers and go on, right?

Well, you might have trouble understanding it, but I think I've made
it clear that both source and abstraction have their benefits.

> But the abstraction thingie was a nice diversion.

Yeah, a 'diversion' I cleverly included in my very first post in this
thread.

What kind of idiot are you?