Doesnt it make sense for a database company to provide ODBC drivers for its database?  That way many other companies can use it also driving up the demand for the database as a whole.  Leaving the driver as a purchase only product or crippled to 3 users means that many companies will look elsewhere.    Also if you purchase the database software.. example me.  VCL CS with source code.. wouldnt including an ODBC driver (even without source) a necessary part of the distribution?   I mean not all vcl applications are written to only use DBISAM  how about if I want to use DBISAM/ELEVATEDB as my primary database but allow the user to switch to another type of database.  If I did this then I would have to design my application to be flexible.  maybe even using odbc  if so.. then I have to buy the odbc driver and source (which I didnt need) at a pretty steep price.    

so.. how can I get the ODBC driver thats not crippled?  Some developers might even be tempted to download a demo of somebody elses software that uses dbisam and odbc jsut to get the odbc dll..

Jack Tackett wrote:

> Does it not make sense for a database company to provide ODBC drivers
> for its database?  That way many other companies can use it also
> driving up the demand for the database as a whole.  Leaving the
> driver as a purchase only product or crippled to 3 users means that
> many companies will look elsewhere.    Also if you purchase the

Only Tim can answer that since he owns the company can do whatever he
wants - it's his product.

However, Elevate is not selling end user databases - both DBISAM and
EDB are meant for developers to embed in their applications.

You pay for the developer license and then can deploy it royalty-free.
Hence it's a one time cost only which makes it very reasonable IMHO.


> database software.. example me.  VCL CS with source code.. wouldnt
> including an ODBC driver (even without source) a necessary part of
> the distribution?   I mean not all vcl applications are written to
> only use DBISAM  how about if I want to use DBISAM/ELEVATEDB as my
> primary database but allow the user to switch to another type of
> database.  If I did this then I would have to design my application
> to be flexible.  maybe even using odbc  if so.. then I have to buy
> the odbc driver and source (which I didnt need) at a pretty steep
> price.

Normally you would choose to write either in VCL or ODBC but likely not
both at the same time. You either want the native power of VCL or if
you wish to be generic then go ODBC route but i don't see a need to mix
the 2 in single app (or you'd have to write the actual code twice to
handle both cases).

Also to repeat previous point - this is meant for developers so it's
one time cost to you.  You can decide what you distribute to your
clients and what you charge them.

> so.. how can I get the ODBC driver thats not crippled?  Some
> developers might even be tempted to download a demo of somebody elses
> software that uses dbisam and odbc jsut to get the odbc dll..

What do you mean exactly by ODBC driver being crippled?  I was not
aware of that though i'm not a big ODBC user. Are you referring to the
5 connection EDB server that comes with DAC Standard?

If so and if you already have the full "VCL CS with source code" then
you already have a unlimited connection EDB server from there.

Raul

Jack,

<< Doesnt it make sense for a database company to provide ODBC drivers for
its database?  That way many other companies can use it also driving up the
demand for the database as a whole. >>

Yes, and those other companies charge per-seat licenses or give away their
entire product line for free.  We do neither of those things.   Our products
all include royalty-free distribution, so we have to capture all of our
income at the initial point of sale.

<< Leaving the driver as a purchase only product or crippled to 3 users
means that many companies will look elsewhere. >>

Which companies are you referring to ?  If you write an application that
needs to use the ODBC driver, either as the primary access method, or for
external access by the customer, and you then distribute that application to
hundreds or thousands of users, why do you think that we don't deserve to be
paid for producing the driver ?  Remember, our driver doesn't just access
some database server that must be licensed separately - it contains the
entire database engine for local connections.

<< Also if you purchase the database software.. example me.  VCL CS with
source code.. wouldnt including an ODBC driver (even without source) a
necessary part of the distribution?   I mean not all vcl applications are
written to only use DBISAM  how about if I want to use DBISAM/ELEVATEDB as
my primary database but allow the user to switch to another type of
database.  If I did this then I would have to design my application to be
flexible.  maybe even using odbc  if so.. then I have to buy the odbc driver
and source (which I didnt need) at a pretty steep price. >>

In such a case you would only need to purchase the EDB-ODBC-STD product, and
you would also get a 20% cross-upgrade discount due to the fact that you
already own a EDB-VCL product.

<< so.. how can I get the ODBC driver thats not crippled?  Some developers
might even be tempted to download a demo of somebody elses software that
uses dbisam and odbc jsut to get the odbc dll..  >>

And that somebody would be illegally using the software, and committing
piracy if they were to actually distribute that driver to their customers.
Furthermore, if that somebody were to ask for support in using or
distributing the driver, they would be considered a first-class jerk.

--
Tim Young
Elevate Software
www.elevatesoft.com

I meant no offense guys.  Here is my example..
I develop an application VCL based with all the database code embedded.  As you mentioned.  And I try to sell the application and data as open/portable/secure/flexible and so on.  But I run into some roadblocks as the data isnt really that accessible.  not unless I write all the apps that talk to it.

but...

I want to use some third party software to get to my data.. Examples include
- crystal reports,
- excel
- Custom software written by other developers (internal to our company) that allow data importation via  ODBC datasources

Now I understand that the 5 user version is not too bad (dac trial)?  but we are not allowed to redistribute it correct?  So I technically couldnt use it to do any of the above things in a production environment I dont think.

Thats why I thought is made sense to distribute the ODBC driver.. Nothing more.  It seems like something that would help developers sell the idea that the data was not just an island and that it was accessible.  

>Jack Tackett wrote:
> Thats why I thought is made sense to distribute the ODBC driver..
> Nothing more.  It seems like something that would help developers
> sell the idea that the data was not just an island and that it was
> accessible.

As Tim said all you need to do is buy the "ElevateDB DAC Standard" for
$279 - with the 20% discount it's actually $223.

Look at it this way - your total cost is the sum of the VCL+DAC
editions - but you only pay once so whether you have 5 or 25 or 125
users there is no additional cost to you.

Once you have them you can distribute both the VCL embedded one with
your application as well as provide ODBC access to the same data for
reporting tools or what have you.

Since you already said you have the VCL CS version with unlimited
server you can forget about the 5 user limit - it does not apply.
You would be using the server from VCL with your app (for CS app) and
ODBC against same server so it's unlimited users.

Finally, i think EDB pricing is in-line (or less than) other commercial
db solutions for Delphi and both product and support is excellent based
on my experience.

Raul

I have to agree with Raul. Elevate Software products have been *very*
competitvely priced, most times less than their competitors. Remember,
Tim has to make a living.

Would you rather he include the ODBC product in the VCL product but
charge $279 more for the entire package for something you might not
need? Many of us who do not need the ODBC would rather pay for what we
*DO* need and let those who need more (like yourself) pay for what you
need.

This is Business 101. Why do you think that McDonalds (the fast-food
conglomerate) charges one price for their hamburger alone and more for
a hamburger with fries and a drink? Why should Tim's business be any
different?

If you sell your software, you would purchase the ODBC/DAC product and
then charge a different price to those who don't want to use your
product *AS IS* (i.e., all VCL), having your customers absorb your cost
of allowing them to access your data.

I recommend you check your library for sources on business marketing
for additional information.

--

Jack Tackett wrote:

> Thats why I thought is made sense to distribute the ODBC driver..
> Nothing more.  It seems like something that would help developers
> sell the idea that the data was not just an island and that it was
> accessible.

Raul Sinimae wrote:

> Normally you would choose to write either in VCL or ODBC but likely
> not both at the same time. You either want the native power of VCL or
> if you wish to be generic then go ODBC route but i don't see a need
> to mix the 2 in single app (or you'd have to write the actual code
> twice to handle both cases).

I have a need for both, for two reasons:

1) My main application is VCL, but I have some customers that want to
have the ability to add a customer record directly from a web page.
The customer navigates to the customers website and fills out a form
which can then update the database directly with the customer name and
address, eliminating the need for an employee to retype the information
into the VCL application.

2) Some customers know how to use Microsoft products like Access,
Excel, or Word and want to access the database directly to do their own
thing with it in these microsoft products.  For example, even though
the customer can do their own mail merge with the built-in report
writer we provide, they might be more comfortable using Word. Having an
ODBC connection allows them to use the product with which they are
familiar.

David Miller wrote:

> I have a need for both, for two reasons:

Both of these are very valid and you simply need to buy both the VCL
and DAC (ODBC/.Net) version of the components.

Neither of these though is same as original question - that was more
about using embedded version and also supporting ODBC in the same app
so you could run with any other DB back-end. That's how i understood
the question anyways.

Raul

Ah, yes, I had trouble understanding that in the original question, but
reading it again now, I can see that is what he was asking.

Based upon this thread, it sounds like the ODBC driver is sold at a one
time price.  I like that very much.  NexusDB use to have their license
like that, but they switched to a per seat licensing model which is
difficult for me.  I don't have a lot of users wanting ODBC, but I like
being able to offer it to them.  I like paying a one-time price for the
technology and then being able to use it.  I do not like having to
negotiate per seat licenses, or buying licenses that I may not use in
order to get the volume discount, etc.  Too complicated.  ElevateDB is
doing it the right way for somebody in my position.

I have been using Delphi 2007, but with Delphi XE out now, I think it
is time for me to make the jump to unicode.  That means my license with
NexusDB for ODBC is worthless, and to upgrade, I will have to start
doing their per seat licensing model, which I do not like.  ElevateDB's
licensing scheme looks much more attractive to me.

Thanks for your comments in this thread.  It has helped me understand.


Raul Sinimae wrote:
> Neither of these though is same as original question - that was more
> about using embedded version and also supporting ODBC in the same app
> so you could run with any other DB back-end. That's how i understood
> the question anyways.

Jack,

Just to let you know, with the up-coming native PHP extension for ElevateDB,
which will be free for download for 30 days, we're also considering
splitting up the pricing into a more "a la carte" type of scheme for the DAC
product, whereby we'll possibly have an EDB-PHP, EDB-ODBC, and EDB-NET type
of offering, with discounts for purchasing more than one.  That will reduce
the pricing for the ODBC driver alone, but will still allow people to
purchase multiples for around the same price as before.  Just to clarify,
though, we're just considering it at this point - it isn't written in stone
yet.

--
Tim Young
Elevate Software
www.elevatesoft.com