Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 21 to 30 of 70 total |
Version 3.30 for Delphi 2007 |
Wed, May 2 2007 1:33 PM | Permanent Link |
"J. B. Ferguson" | 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 |
Wed, May 2 2007 3:45 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Wed, May 2 2007 6:23 PM | Permanent Link |
Bill Mullen | >>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 |
Wed, May 2 2007 9:49 PM | Permanent Link |
Dave M | 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 |
Thu, May 3 2007 1:21 AM | Permanent Link |
Bill Mullen | 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 > |
Thu, May 3 2007 1:42 AM | Permanent Link |
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 |
Thu, May 3 2007 5:12 AM | Permanent Link |
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. Still ... I'm glad to have found a solution for my situation. Thank you all for your input on the matter. |
Thu, May 3 2007 11:59 AM | Permanent Link |
"Walter Matte" | 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. > |
Thu, May 3 2007 12:58 PM | Permanent Link |
> 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/ | |
Thu, May 3 2007 3:45 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
« Previous Page | Page 3 of 7 | Next Page » |
Jump to Page: 1 2 3 4 5 6 7 |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |