Dave,

<< My comments were not aimed at Elevate, although, rereading them, it is
understandable that they might be interpreted so. They were meant to be
general.  I just got done looking at some other 3rd party tools. In response
to the difficulties of supporting previous versions, things do seem to be
headed toward subscription. In the case of DBISAM, the help provided for
previous versions, so far does not seem to have an expiration. This is
"going the extra mile" and very good customer relations. >>

We do try to support older versions as much as possible, but there are
limits due to my brain going "stale" since I haven't worked with the older
versions in so long.  Plus, there is a certain fatigue factor after a while
when one is asked about a support issue that has been fixed in a newer
version for a couple of years.  Unfortunately, not all issues can be fixed
in the same major release due to the issue being caused by an architectural
flaw.  These are the types of issues that we target first with respect to
new major releases.

<< It generally is going a little too far to "expect", ("demand", "feel 100
percent entitled to"), a new build; however, depending on circumstances, it
might not be unreasonable to "expect" (as in "hope", or "having a sense of
being treated more than fairly") to receive the build. Delphi has always had
the DCU version issue. There could be no changes to source and still old
DCUs are unusable. It seems to me it depends on the amount of work involved.
If it were just a build, then it would be good customer relations. That
doesn't mean a customer can expect a zero cost build, but the question is:
"Does this justify a full upgrade cost?" >>

I would say, in some cases, that the answer is no.  However, we have to be
fairly rigid in enforcing how we sell our products, and it really just isn't
good business for us to constantly make exceptions for the fact that someone
decided not to purchase the available source code several years ago when
they had the chance.

<< It was mentioned at one time by Tim that the plan was that 4 would be the
last (not the exact words) in the DBISAM series. Not sure where that stands
now. >>

That most likely will be the case.  Right now I can't see us doing another
major DBISAM release in the next year.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>We do try to support older versions as much as possible, but there are
>limits

I have wondered more than once how you do it.  

>I would say, in some cases, that the answer is no.  However, we have to be
>fairly rigid in enforcing how we sell our products, and it really just isn't
>good business for us to constantly make exceptions for the fact that someone
>decided not to purchase the available source code several years ago when
>they had the chance.

Is there an official policy to make things clear? (Like no new builds for old versions.)
It's hard to tell a customer no, but sometimes you have to.  When that happens, it seems
to me that it is important that they "feel" treated fairly and consistently.


>Right now I can't see us doing another major DBISAM release in the next year.

I would hope you don't (ever). I would rather see you get EDB scripting, .net, and odbc,
and tools up to par with or better than DBISAM.  (Not to mention replication.) But then I
haven't thought through any/all possible issues with apps that need to be ported, nor
issues with DBISAM users, who might be disappointed/irked at having to port.  For myself,
I see the port as moderately difficult, due in large part to my own at times "less than
optimal" coding practices.

Dave M

Dave


>For myself,
>I see the port as moderately difficult, due in large part to my own at times "less than
>optimal" coding practices.

If you add in an aging and incompetent brain (SQL is still largely a mystery) you have just described me!

Roy Lambert

Roy Lambert wrote:

If you add in an aging and incompetent brain (SQL is still largely a mystery) you have
just described me!
-----------------------------------------------------------------------------------------------------------------------

I'm no expert at it; I'm not even proficient. I do have 2 college textbooks on database
systems, but that is mostly background, theory, and the basics of SQL. Background helps,
but that doesn't imply proficiency, especially not after a considerable lapse of time
since studying.

Did you get the book Ole suggested? I might consider it myself.
If so, did it cover any basic relational database theory?  I studied theory before SQL.
Without the theory, for me, SQL would *really* be a mystery. At least with some background
I probably can hack a solution, after some time and effort.

As far as aging, well you aren't the only one "over the hill."

Dave M

I do have the 4.xx version of DBISAM, but I need for some projects to use v.3 - projects
that have many users (10.000+)  and a rollout of a new version of the database is not what
is needed right now. If you have worked in technical support, you'll understand why. Above
all, the version 3 is performing well and is no need to do the upgrade in this situation.

I had expected that a simple task like provinding D2007 compatibility for. v3  to be
already done. The good engineers that did DBISAM are the most entitled to do the fixes
required. And this service is expected, especially for loyal clients that did the upgrade
to v. 4. In the end is a small service, not a  time consuming one, that would made a big
difference in the level of service we were used to receive here at DBISAM.

Maybe is not too late to offer this. I see I am not the only one with such a demand.

Dave

>Did you get the book Ole suggested?

Not yet. My current task is beating the TMS components into submission

Roy Lambert

Dan


I'm on Tim's side here. Buy the source and recompile it, or pay Tim consultancy rate to do the upgrade. If its simply a matter of opening D2007 and recompiling it won't cost much

Roy Lambert

Dan,

you are a professional software developer. Tim is a professional
software developer. As we nearly all are.
If you have projects with 10.000+ users then it should not be an issue
at all to buy the source version and do what is rquired.

Arnd

Dan wrote:

> I had expected that a simple task like provinding D2007 compatibility
> for. v3  to be already done.

So should we also expect new builds of Dbisam v.1 for D2007?  This is
really an odd expectation, given that very few, if any,  vendors
continue to provide builds for previous editions.  That is one of the
benefits of purchasing the source code. At least then you can do it on
your own, since it is such a "simple task".

Saving money by not buying the source and then expecting the vendor to
keep providing new builds for a previous product is really asking for
too much, IMHO. My suggestion, already mentioned by Tim, is buy the
source for v.4.0 and you also get the source for 3.XX.  Problem solved.

--
David Farrell-Garcia
Whidbey Island Software, LLC

>Dan wrote:

>I do have the 4.xx version of DBISAM, but I need for some projects to use v.3 - projects
>that have many users (10.000+)  and a rollout of a new version of the database is not what
>is needed right now.

>I had expected that a simple task like provinding D2007 compatibility for. v3  to be
>already done. The good engineers that did DBISAM are the most entitled to do the fixes
>required. And this service is expected, especially for loyal clients that did the upgrade
>to v. 4. In the end is a small service, not a  time consuming one, that would made a big
>difference in the level of service we were used to receive here at DBISAM.


In my posts I raised some thoughts about when/if builds should be provided. On one hand, I
wouldn't like to see a customer "feeling" treated unfairly. On the other hand, a customer
without source can not really lay claim to free builds indefinitely. In certain instances,
it is good customer relations. In other instances, demands for builds can border on
"freeloading".  I'm not really sure how much work would be involved. It might be easy, or
it might be one more thing that looks easy and turns out time consuming. It's a bit messy,
not always clearcut, and in the end the vendor is forced to implement a policy involving
some kind of cut off.

Elevate has first class support. If I were in Tim's position, I really don't know what I
would do. If I had a lot of users for my current DBISAM project, I might insist that
everyone have the current version or zero updates, and possibly zero support. I'm really
not fast enough / gifted enough to dilute my time with multiple versions.

What really doesn't make sense is your original urgent (almost panicked) request, followed
by your statements that you have 10,000 users and no source. Honestly, in the Delphi
environment, it is well known that you are asking for bigger problems than what you have
right now. Zero DCU version compatibility has been the rule. You could be stuck with no
options, no source, no support. If you were "Joe working out of his basement, unable to
pay bills and looking for customer #1", I would sympathize. As it is, something doesn't
add up. I would not even consider doing a project for 1 customer without source. Consider
the potential problems for you and your customers.

Dave M