Dan,

<<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.

If it is necessary for you to keep products using DBISAM v3.x then it
will also be necessary for you to keep running whatever version of
Delphi needed to compile your application. Since multiple versions of
Delphi will co-exist on a system, this should not be an issue for you.

<<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.

If you know this to be the "simple task" you say it is, purchase the
source code for v3 (as Tim stated you will also get the source for v4
as well) and create the "fix" yourself. To be honest, a professional
developer would purchase the source code so as to never be in this type
of position. Further, it's my opinion that you shot yourself in the
foot and lost a lot of credibility when you said, "And this service is
expected, especially for loyal clients..." IMHO, that's an arrogant
thing to say.

Just my 2 cents worth.

--
Regards,
Jan Ferguson

Dan,

<< 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. >>

You're not seeing the whole picture.  We're talking about source code that
hasn't been touched in years, and more importantly, hasn't been built using
our automated build system in years.  In other words, I'm not even sure if I
could build a version 3.x or earlier right now without major work since I
haven't been updating the 3.x or earlier build scripts, manuals, etc. since
2003 or 2004.  The build system is updated constantly to deal with
improvements in our PDF manuals, help files, what examples we provide, etc.
It's just not as simple as popping the source code into the Delphi IDE and
clicking on the Build menu option.

--
Tim Young
Elevate Software
www.elevatesoft.com

>>David Farrell-Garcia wrote:
>>It did not go stale.  It got a new version.  
>
>Same thing. Like all software, things moved on. That version can no longer be used with
>the current Delphi, so 3.3 is "stale."

But it *will* work with the current version of Delphi, *if* you have
source and make very very few modifications.

Took me about 3 minutes to get it working in D2007 - of course I am
still testing the app though but so far, I haven't run into any
snags...

- Bill

Bill Mullen wrote:

>But it *will* work with the current version of Delphi, *if* you have
>source and make very very few modifications.

>Took me about 3 minutes to get it working in D2007 - of course I am
>still testing the app though but so far, I haven't run into any
>snags...

This has become the thread that won't die I had planned on making my last post be my
*last post*.

Testing is a big issue. Whatever parts depend on existing vcl code may break. When and
where is uncertain without carefully examining vcl source. When compiled code is released,
there is an obligation/liability created. I didn't originally think about this.

After committing to furnish updates to a program in the next several days, I thought might
as well upgrade to 2007. Risky move, but it didn't seem like a big problem. Then I started
having some issues, at least one of which is a Delphi problem.  ComboBox items just
disappear sporadically. It seems to be related to opening and closing forms in the
designer. This involves either reverting back to a previous compiler, or workarounds. In
this case it is a simple workaround. I can't believe how complicated simple things get...

Dave M

Yep, I have experienced that problem (ComboBox items) just recently.
Do you know if it has been QC'd or not?


>Bill Mullen wrote:
>
>>But it *will* work with the current version of Delphi, *if* you have
>>source and make very very few modifications.
>
>>Took me about 3 minutes to get it working in D2007 - of course I am
>>still testing the app though but so far, I haven't run into any
>>snags...
>
>This has become the thread that won't die I had planned on making my last post be my
>*last post*.
>
>Testing is a big issue. Whatever parts depend on existing vcl code may break. When and
>where is uncertain without carefully examining vcl source. When compiled code is released,
>there is an obligation/liability created. I didn't originally think about this.
>
>After committing to furnish updates to a program in the next several days, I thought might
>as well upgrade to 2007. Risky move, but it didn't seem like a big problem. Then I started
>having some issues, at least one of which is a Delphi problem.  ComboBox items just
>disappear sporadically. It seems to be related to opening and closing forms in the
>designer. This involves either reverting back to a previous compiler, or workarounds. In
>this case it is a simple workaround. I can't believe how complicated simple things get...
>
>Dave M
>

>Bill Mullen <noprivateemail@domain.com> wrote:

>Yep, I have experienced that problem (ComboBox items) just recently.
>Do you know if it has been QC'd or not?


Quality Central #44777. At first it didn't look too good for getting fixed too soon
(unable to duplicate).
Now it looks like it might.

Dave M

Of course, I've already bought the source code, it's in the nature of a developer to find
solutions. But I've felt the need to express a degree of disappointment with the issue. I
think that supporting only the last version of a product is a mistake, big as the client
base still using, for some reason, the previous version. If they are clients willing to
pay, you must do the did and provide what they are asking. There will be nice to have un
upgrade option ... D2007 install kit for v.3 cost you X thank you banknotes.

Still ... I'm glad to have found a solution for my situation. Thank you all for your input
on the matter.

Wow, so committed to DBISAM and with that many users and you didn't purchase
source?

I am with Tim.  But I make it a point to ALWAYS buy source.


Walter


"Dan" <adm77@email> wrote in message
news:85309998-B04F-4751-A57A-D4A6A2355480@news.elevatesoft.com...
>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.
>

> 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.

FWIW, I think I would too. DBISAM is a great database, but I can see that
there are things that ElevateDB will take to a new level. Better to keep
DBISAM supported and stable and make ElevateDB better. Then people can
choose where to take code.

/Matthew Jones/

Dan,

<< Of course, I've already bought the source code, it's in the nature of a
developer to find solutions. But I've felt the need to express a degree of
disappointment with the issue. I think that supporting only the last version
of a product is a mistake, big as the client base still using, for some
reason, the previous version. If they are clients willing to pay, you must
do the did and provide what they are asking. There will be nice to have un
upgrade option ... D2007 install kit for v.3 cost you X thank you banknotes.
>>

Actually, in a lot of cases it costs us more than that.  The fact is that if
we continue to provide updates to a version, then we are obligated to keep
providing bug fixes and new updates.  IOW, doing what you suggest causes a
major version of DBISAM to become a zombie that never dies.

I'm just not sure in this case if you appreciate how much time is required
to maintain a current major version of DBISAM or ElevateDB.  What you're
suggesting would involve maintaining at least 3 major versions of DBISAM and
ElevateDB for the forseeable future.

When would you suggest that we should have stopped providing updates for 3.x
?  Should we have kept it going until Delphi 2008, 2009, etc. ?  Eventually
we *do* have to stop providing updates for a major version, so why was our
decision bad (3.x was 2 years old when we froze it) compared to a later
decision ?  At some point you're simply going to make someone mad no matter
what you do.  The issue is how to balance that against the amount of
time/money it costs to keep a major version alive.  We thought that the 2
years was fair given the upgrade pricing for 4.x and the fact that we
announced it several times in advance.

--
Tim Young
Elevate Software
www.elevatesoft.com