Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: How to avoid maintenance nightmare with discontinued components


This question is answered.


Permlink Replies: 26 - Last Post: Sep 24, 2014 4:57 AM Last Post By: Eduardo Elias
Nico Callewaert

Posts: 22
Registered: 5/9/02
How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 18, 2014 2:58 PM
Hi,

I don't know if I had to post this in the database section or not, anyway, I'm wondering if there is a way to avoid a maintenance nightmare with suddenly discontinued components. We are migrating a large application from Delphi 7 to XE5. A year ago, the vendor of our database connectivity suite (FIBPlus) decided, without informing their customers to declare the product dead. The components are no longer available for XE5. We have lot's of forms and datamodules (hundreds). Now I can start to replace them one by one with FireDac components. But I'm wondering if that is the right approach. Who knows if FireDac will be gone one day, I can start all over again. So my question is if this is really the only and right approach, or if there is a more professional way to do this ? I was thinking about a black box, a class with the component inside, shielded from the outside world, so when the component is replaced, it's only the internals that has to change, the class from the outside will remain intact. But this will only work if 2 different dataset components have exactly the same properties and events. Example component A has a property : SelectSQL. In component B, that property is called : SQL. So what if you black box component A and later replace it with component B, there wil be already a conflicht with that property name. And it's not only 1 property, there will be several more, also events will be different. I could use a memtable to store loaded data but that's a non starter because with large datasets it's a performance killer. So I'm a little stuck in the mud about the correct way to replace these components without compromising on performance.

Many thanks in advance !
Best regards, Nico
Dan Palley

Posts: 43
Registered: 2/14/00
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 18, 2014 5:43 PM   in response to: Nico Callewaert in response to: Nico Callewaert
As long as you have the source to your components, you should be able to maintain them for a few versions after the vendor stops supporting. We've been doing this for ReportPrinterPro (pre-Rave) for years now. At some point, though, it makes sense to move to the latest tech. I feel that Delphi has very good backward-compatibility for it's native database components -- heck, they still (barely) support the BDE some 15 years later.

Dan

Nico Callewaert wrote:
Hi,

I don't know if I had to post this in the database section or not, anyway, I'm wondering if there is a way to avoid a maintenance nightmare with suddenly discontinued components. We are migrating a large application from Delphi 7 to XE5. A year ago, the vendor of our database connectivity suite (FIBPlus) decided, without informing their customers to declare the product dead. The components are no longer available for XE5. We have lot's of forms and datamodules (hundreds). Now I can start to replace them one by one with FireDac components. But I'm wondering if that is the right approach. Who knows if FireDac will be gone one day, I can start all over again. So my question is if this is really the only and right approach, or if there is a more professional way to do this ? I was thinking about a black box, a class with the component inside, shielded from the outside world, so when the component is replaced, it's only the internals that has to change, the class from the outside will remain intact. But this will only work if 2 different dataset components have exactly the same properties and events. Example component A has a property : SelectSQL. In component B, that property is called : SQL. So what if you black box component A and later replace it with component B, there wil be already a conflicht with that property name. And it's not only 1 property, there will be several more, also events will be different. I could use a memtable to store loaded data but that's a non starter because with large datasets it's a performance killer. So I'm a little stuck in the mud about the correct way to replace these components without compromising on performance.

Many thanks in advance !
Best regards, Nico
Ole Ekerhovd

Posts: 50
Registered: 2/20/03
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 18, 2014 8:50 PM   in response to: Nico Callewaert in response to: Nico Callewaert
I abandoned data aware components years ago, because of the reasons you mention.

I don't use any data aware edit fields, grids etc. at all.

My program uses sql and fills ordinary edit fields, grids etc. manually. All inserts and edits are done manually through sql.

A lot of extra coding, but now I can switch database components "in seconds" if necessary.

Regards

Ole
Vladimir Ulchenko

Posts: 248
Registered: 1/12/00
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 18, 2014 10:44 PM   in response to: Ole Ekerhovd in response to: Ole Ekerhovd
On Thu, 18 Sep 2014 20:50:35 -0700, Ole Ekerhovd <> wrote:

I abandoned data aware components years ago, because of the reasons you mention.

had you utilized multitier approach (say midas) you wouldn't have to abandon it

I don't use any data aware edit fields, grids etc. at all.

over the time of 10+ years I changed database backend (from mssql to oracle) and several data access components including bde, ado, doa,
anydac without really touching front end user applications full of data-aware components. all I needed to change were application servers
switching from one dac suite implementing IProviderSupport interface to another. some apps even still have the abilty to switch from one dac
to another simply by changing one param value, I mean there are still "parallel" remote data module implementations in a single appserver
that decide which one to instantiate when new client establishes connection

--
Vladimir Ulchenko aka vavan
Lorne Anderson

Posts: 21
Registered: 9/17/08
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 19, 2014 4:21 AM   in response to: Nico Callewaert in response to: Nico Callewaert
On 18/09/2014 22:58, Nico Callewaert wrote:
Hi,

I don't know if I had to post this in the database section or not, anyway, I'm wondering if there is a way to avoid a maintenance nightmare with suddenly discontinued components. We are migrating a large application from Delphi 7 to XE5. A year ago, the vendor of our database connectivity suite (FIBPlus) decided, without informing their customers to declare the product dead. The components are no longer available for XE5. We have lot's of forms and datamodules (hundreds). Now I can start to replace them o
ne by one with FireDac components. But I'm wondering if that is the right approach. Who knows if FireDac will be gone one day, I can start all over again. So my question is if this is really the only and right approach, or if there is a more professional way to do this ? I was thinking about a black box, a class with the component inside, shielded from the outside world, so when the component is replaced, it's only the internals that has to change, the class from the outside will remain intact. But this w
ill only work if 2 different dataset components have exactly the same properties and events. Example component A has a property : SelectSQL. In component B, that property is called : SQL. So what if you black box component A and later replace it with component B, there wil be already a conflicht with that property name. And it's not only 1 property, there will be several more, also events will be different. I could use a memtable to store loaded data but that's a non starter because with large datasets it
's a performance killer. So I'm a little stuck in the mud about the correct way to replace these components without compromising on performance.

Many thanks in advance !
Best regards, Nico
Never use a component if you do not have the source code.
Lajos Juhasz

Posts: 801
Registered: 3/14/14
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 19, 2014 7:46 AM   in response to: Nico Callewaert in response to: Nico Callewaert
Nico Callewaert wrote:

Hi,

I don't know if I had to post this in the database section or not,
anyway, I'm wondering if there is a way to avoid a maintenance
nightmare with suddenly discontinued components.

For me the most important rule is never to use any component directly.
Always subclass the every single component you’re going to use. In the
first version it can be look just like this:

TMyEdit = class(TEdit);


Maybe not for all the components but for some over the time you will
add some properties or methods.

The visual components I started with VCL then moved them to TNT (in
order to support Unicode) and finally moved back to VCL when Unicode
enabled VCL come out. On the database side my road was BDE to DBExpress
and finally FireDAC. With every migration there was some difference in
properties that can require that you add a dummy property or to rename
a property. However you can do that in your classes without touching
the forms.

The worst case scenario for me was to build utilities to move the code.
For example FireDAC required changing data type for fields. Once again
a utility finished that for me in 95% of my code. 5% remained to be
corrected as a result as a bug defect from the test team and automated
tests.
Marius Ellen

Posts: 64
Registered: 11/22/99
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 19, 2014 12:04 PM   in response to: Lajos Juhasz in response to: Lajos Juhasz
Lajos Juhasz wrote:

Nico Callewaert wrote:

Hi,

I don't know if I had to post this in the database section or not,
anyway, I'm wondering if there is a way to avoid a maintenance
nightmare with suddenly discontinued components.

For me the most important rule is never to use any component directly.
Always subclass the every single component you’re going to use. In the
first version it can be look just like this:

TMyEdit = class(TEdit);


If that is working for you, no problem, but we have done that in the
past and dumped it in the end. It is impossible to maintain with huge
number of component sets and you can never exchange the components
underneath as each have its own set of properties stored in the dfm's
so very little advantage in subclassing.

The only proper way would be to use mvc or opf with a proper database
backend, basicly that is saying stay away from the delphi RAD appoach.
Lajos Juhasz

Posts: 801
Registered: 3/14/14
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 22, 2014 4:18 AM   in response to: Marius Ellen in response to: Marius Ellen
Marius . wrote:

Lajos Juhasz wrote:

Nico Callewaert wrote:

Hi,

I don't know if I had to post this in the database section or not,
anyway, I'm wondering if there is a way to avoid a maintenance
nightmare with suddenly discontinued components.

For me the most important rule is never to use any component
directly. Always subclass the every single component you’re going
to use. In the first version it can be look just like this:

TMyEdit = class(TEdit);


If that is working for you, no problem, but we have done that in the
past and dumped it in the end. It is impossible to maintain with huge
number of component sets and you can never exchange the components
underneath as each have its own set of properties stored in the dfm's
so very little advantage in subclassing.

The only proper way would be to use mvc or opf with a proper database
backend, basicly that is saying stay away from the delphi RAD appoach.

That's true that a different component set can have different
properties. In those cases I just wrote a simple translator to change
the properties as required. By sub classing I just save a couple of
search and replace in files operation (on a larger codebase that can
save time). If you have own component set then you can pretty fast
change the behavior of the application.
Eduardo Elias

Posts: 319
Registered: 9/20/12
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 24, 2014 4:57 AM   in response to: Lajos Juhasz in response to: Lajos Juhasz
just my 2 cents:

I am also subclassing the components.

The RAD fever has passed. Write good programs that last many years is not
easy.

The problem is that we sometimes need to use that very cool feature of a
3rd party component, that is there like a honeypot. That cool feature only
them have it. And that is going to bring the edge we are looking for our
software.... that is risky.

Not going RAD way we go the SAD way (slow application dev) that is the real
thing. Subclassing means a lot more of code.

And I prefer not to use those cool features anymore. I prefer to combine
little things creating new compound components that are "mine" try to use
mostly what is part of the IDE already.

When choosing a library I try to get the source code. Not for maintenance,
but to have ways to move to new versions of IDE if needed. Few years ago
I got DBISAM with source and mantained it for while. Then I decided not to
upgrade anymore and I could take it from XE to XE5 with no problem. I had
to change the source code a little. Tested with my application and worked.
It was already a solid product. Now I am moving to ElevateDB that I got with
Source Code either.

Same thing with TMS products. I buy with code, stick with what is important,
resist the cool features. I like nice and advanced UIs, however that needs
a lot of investment. So I changed my mind to invest in architecture that
will let this happen some point in the future.

Marius . wrote:

Lajos Juhasz wrote:

Nico Callewaert wrote:

Hi,

I don't know if I had to post this in the database section or not,
anyway, I'm wondering if there is a way to avoid a maintenance
nightmare with suddenly discontinued components.
For me the most important rule is never to use any component
directly. Always subclass the every single component you’re going
to use. In the first version it can be look just like this:

TMyEdit = class(TEdit);
If that is working for you, no problem, but we have done that in the
past and dumped it in the end. It is impossible to maintain with huge
number of component sets and you can never exchange the components
underneath as each have its own set of properties stored in the dfm's
so very little advantage in subclassing.

The only proper way would be to use mvc or opf with a proper database
backend, basicly that is saying stay away from the delphi RAD
appoach.
That's true that a different component set can have different
properties. In those cases I just wrote a simple translator to change
the properties as required. By sub classing I just save a couple of
search and replace in files operation (on a larger codebase that can
save time). If you have own component set then you can pretty fast
change the behavior of the application.
Vladimir Ulchenko

Posts: 248
Registered: 1/12/00
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 21, 2014 11:17 PM   in response to: Lajos Juhasz in response to: Lajos Juhasz
On Fri, 19 Sep 2014 07:46:25 -0700, Lajos Juhasz <juhasz dot lajos at gmail dot com> wrote:

For example FireDAC required changing data type for fields. Once again

with the FireDAC you could use its field types mapping feature to lessen the hours of work

--
Vladimir Ulchenko aka vavan
Lajos Juhasz

Posts: 801
Registered: 3/14/14
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 22, 2014 4:12 AM   in response to: Vladimir Ulchenko in response to: Vladimir Ulchenko
Vladimir Ulchenko wrote:

On Fri, 19 Sep 2014 07:46:25 -0700, Lajos Juhasz
<juhasz dot lajos at gmail dot com> wrote:

For example FireDAC required changing data type for fields. Once
again

with the FireDAC you could use its field types mapping feature to
lessen the hours of work

For me type mapping is a minefield, you never know where you can
introduce a bug using it. For me it was just safer to spend a couple of
additional hours to make sure that every field is the type the driver
expects.
Jason Sweby

Posts: 46
Registered: 5/20/00
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 19, 2014 8:04 AM   in response to: Nico Callewaert in response to: Nico Callewaert
To echo what everyone else has said here, use third-party components that have a good history, or at least to which you have the source code. We got burnt by this a few years ago when ODBCExpress was killed off from Delphi 2007, meaning it was not unicode capable for Delphi 2009 onwards.

I blogged about this extensively (http://delphidisciple.blogspot.co.uk/2013/01/migration-from-delphi-6-to-delphi-xe3.html) and in the end we had little choice but to switch to a different set of components, manually swapping them out. Whilst I understand why some people shy away from using db-aware components all together, this wasn't an option for us but we at least moved to dbGo (ADO) which Borland/CodeGear/Embarcadero have been continuing to support and ship, even up to XE7.
Clement Doss

Posts: 133
Registered: 9/19/00
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 19, 2014 9:16 AM   in response to: Nico Callewaert in response to: Nico Callewaert
Hi,

I guess each one has a set of rules...

1) Always get the source
2) Avoid using too many libraries

I have project I use non DB-aware components, and projects that I use DB-aware components.
While it's true non db-aware have the advantage of not linking directly to a database, using db-aware components with memory datasets on a 3tier architecture is very cool.

I also had this very same problem and it only stopped when I moved to AnyDAC long before it what purchased by EMB. Today I only write RAD client/server using visual links. I moved to 3tier and never looked back ( VCL (or FMX) - > Datasnap -> DB (Through FireDAC or NexusDB) ). With that combo the coulds are no limit :)

Clément

Nico Callewaert wrote:
Hi,

I don't know if I had to post this in the database section or not, anyway, I'm wondering if there is a way to avoid a maintenance nightmare with suddenly discontinued components. We are migrating a large application from Delphi 7 to XE5. A year ago, the vendor of our database connectivity suite (FIBPlus) decided, without informing their customers to declare the product dead. The components are no longer available for XE5. We have lot's of forms and datamodules (hundreds). Now I can start to replace them one by one with FireDac components. But I'm wondering if that is the right approach. Who knows if FireDac will be gone one day, I can start all over again. So my question is if this is really the only and right approach, or if there is a more professional way to do this ? I was thinking about a black box, a class with the component inside, shielded from the outside world, so when the component is replaced, it's only the internals that has to change, the class from the outside will remain intact. But this will only work if 2 different dataset components have exactly the same properties and events. Example component A has a property : SelectSQL. In component B, that property is called : SQL. So what if you black box component A and later replace it with component B, there wil be already a conflicht with that property name. And it's not only 1 property, there will be several more, also events will be different. I could use a memtable to store loaded data but that's a non starter because with large datasets it's a performance killer. So I'm a little stuck in the mud about the correct way to replace these components without compromising on performance.

Many thanks in advance !
Best regards, Nico
Linden ROTH

Posts: 467
Registered: 11/3/11
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 19, 2014 12:25 PM   in response to: Nico Callewaert in response to: Nico Callewaert
Nico Callewaert wrote:

application from Delphi 7 to XE5.

Even if you production version in not kept in the current version its very worth while every 2 to 3 version (and you have skipped about 12 = 12+ years lots of thing are discontinued in that time frame) to do a port to the latest version from the PRODUCTION source to so that the implications of swapping version are 100% clear - this means keeping all components etc - I would suggest a Yearly VM build that is then archived

NB Also it is worth avoid where possible 3rd party products for long term work (and of course NEVER use without source code) - FireDac is not 3rd party

--
Linden
"Mango" was Cool but "Wasabi" was Hotter but remember it's all in the "source"
Roy Lambert

Posts: 1,063
Registered: 8/7/01
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 20, 2014 12:45 AM   in response to: Nico Callewaert in response to: Nico Callewaert
Nico

I've been reading this thread and I'm fascinated by the number of people saying you should always buy the source code. Its a philosophy I used to subscribe to but no more.

In theory this gives you the option of maintaining it yourself. In practice, apart from simple components / libraries I think this is a bit of a pipe dream. Unless you're prepared to invest a lot of time, or the changes are utterly trivial (eg compile using the latest Delphi), or you're totally desperate, then the cost of maintaining it yourself is often higher than buying and using a new component.

Roy Lambert

Ole Ekerhovd

Posts: 50
Registered: 2/20/03
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 20, 2014 1:55 AM   in response to: Roy Lambert in response to: Roy Lambert
+1

Tried that a couple of times, had to give it up.

Ole


In theory this gives you the option of maintaining it yourself. In practice, apart from simple components / libraries I think this is a bit of a pipe dream. Unless you're prepared to invest a lot of time, or the changes are utterly trivial (eg compile using the latest Delphi), or you're totally desperate, then the cost of maintaining it yourself is often higher than buying and using a new component.

Roy Lambert

Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 20, 2014 10:15 AM   in response to: Roy Lambert in response to: Roy Lambert
Roy,

I agree.

--

Q

1.19.1.372 (Q's Broken Toolbar.)

Linden ROTH

Posts: 467
Registered: 11/3/11
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 20, 2014 12:05 PM   in response to: Roy Lambert in response to: Roy Lambert
Roy Lambert wrote:

or the changes are utterly trivial (eg compile using the latest Delphi), or you're totally desperate,

If you have the source you can do this, if you don't then ....

It's called risk mitigation ie if you don't you can't, if you do maybe you can

--
Linden
"Mango" was Cool but "Wasabi" was Hotter but remember it's all in the "source"
Marius Ellen

Posts: 64
Registered: 11/22/99
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 20, 2014 12:08 PM   in response to: Roy Lambert in response to: Roy Lambert
Roy Lambert wrote:

Nico

I've been reading this thread and I'm fascinated by the number of
people saying you should always buy the source code. Its a philosophy
I used to subscribe to but no more.

In theory this gives you the option of maintaining it yourself. In
practice, apart from simple components / libraries I think this is a
bit of a pipe dream. Unless you're prepared to invest a lot of time,
or the changes are utterly trivial (eg compile using the latest
Delphi), or you're totally desperate, then the cost of maintaining it
yourself is often higher than buying and using a new component.


No, that is not what they are saying, they don't maintain the code (or
at least thats not the purpose). As I read it they just want it to just
recompile to the latest delphi environment. Specially if thevendor goes
out of business of is just slow at updating his product. In each update
most of the time only the packages and the include file needs some
tinkering and this works well for a slow moving VCL, i'm not sure if
that works for the fast moving FMX (no experiences there).

Greetings,
Marius
Roy Lambert

Posts: 1,063
Registered: 8/7/01
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 21, 2014 1:41 AM   in response to: Marius Ellen in response to: Marius Ellen
Marius

No, that is not what they are saying, they don't maintain the code (or
at least thats not the purpose). As I read it they just want it to just
recompile to the latest delphi environment. Specially if thevendor goes
out of business of is just slow at updating his product. In each update
most of the time only the packages and the include file needs some
tinkering and this works well for a slow moving VCL, i'm not sure if
that works for the fast moving FMX (no experiences there).

Compiling older code to the latest version I would say comes under the heading of maintenance, especially if code needs changing. If the vendor is still in business then you don't touch the source. Well not unless you're trying to avoid spending money or the vendor doesn't respond to bug reports.

I've owned Addict spell check at least since D4 (might have been earlier). I've never touched the source. On the other hand I use Synapse these days because (again probably D4) I tried to use Indy. There was a bug and I tried to track it down. That took me a couple of days and I still had no idea how to fix it. That piece of software is probably far better maintained these days with Remy.

Roy Lambert
David Novo

Posts: 40
Registered: 8/5/07
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 20, 2014 12:25 PM   in response to: Roy Lambert in response to: Roy Lambert
As a counterpoint to this, we are maintaining at least 6 different libraries that went out of business years ago. For example AutomatedQA (now smartbear) docking library. We have managed to upgrade it to 64 bit and keep it going forward with relatively minimal effort (maybe 50 lines of source had to change). Without the source, it would have taken weeks to migrate to another fully featured docking library with different events, paradigm etc.

Always get the source, for VCL, changes to the language since XE2 and 64 bit have been minimal. Most libraries simply recompile with very few, if any, issues.

Roy Lambert wrote:
Nico

I've been reading this thread and I'm fascinated by the number of people saying you should always buy the source code. Its a philosophy I used to subscribe to but no more.

In theory this gives you the option of maintaining it yourself. In practice, apart from simple components / libraries I think this is a bit of a pipe dream. Unless you're prepared to invest a lot of time, or the changes are utterly trivial (eg compile using the latest Delphi), or you're totally desperate, then the cost of maintaining it yourself is often higher than buying and using a new component.

Roy Lambert

Roy Lambert

Posts: 1,063
Registered: 8/7/01
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 21, 2014 1:37 AM   in response to: David Novo in response to: David Novo
David

As a counterpoint to this, we are maintaining at least 6 different libraries that went out of business years ago. For example AutomatedQA (now smartbear) docking library. We have managed to upgrade it to 64 bit and keep it going forward with relatively minimal effort (maybe 50 lines of source had to change). Without the source, it would have taken weeks to migrate to another fully featured docking library with different events, paradigm etc.

That's good to hear. How long did it take you to find those 50 lines of code?

Always get the source, for VCL, changes to the language since XE2 and 64 bit have been minimal. Most libraries simply recompile with very few, if any, issues.

The original post referred to moving from D7 to XE5. I have no idea how minimal that is since I've never done it. I do remember migrating some free stuff from Torry from D4 to D6. I joined Delphi at D1 so I had a reasonable amount of experience. Ultimately the easiest way was to delete all IFDEFS, removing older (pre D4 code) manually then try and compile and sort problems out. A simple component but it still took many hours.

Roy Lambert
Nico Callewaert

Posts: 22
Registered: 5/9/02
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 21, 2014 11:44 PM   in response to: Roy Lambert in response to: Roy Lambert
Hello Roy,

I agree with you. I looked already at the source code and it's far from simple to find bugs or to add new functionality when the DB version changes. I guess it will just invite more bugs...

Thx !

Roy Lambert wrote:
Nico

I've been reading this thread and I'm fascinated by the number of people saying you should always buy the source code. Its a philosophy I used to subscribe to but no more.

In theory this gives you the option of maintaining it yourself. In practice, apart from simple components / libraries I think this is a bit of a pipe dream. Unless you're prepared to invest a lot of time, or the changes are utterly trivial (eg compile using the latest Delphi), or you're totally desperate, then the cost of maintaining it yourself is often higher than buying and using a new component.

Roy Lambert

Rael Bauer

Posts: 228
Registered: 10/10/02
Re: How to avoid maintenance nightmare with discontinued components
Correct
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 21, 2014 11:35 AM   in response to: Nico Callewaert in response to: Nico Callewaert
I suggest you look at the devart.com components. I know that their
UniDAC has a migration wizard for FIBPlus, I assume their IBDAC also does...

-Rael
Nico Callewaert

Posts: 22
Registered: 5/9/02
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 21, 2014 11:47 PM   in response to: Rael Bauer in response to: Rael Bauer
Hi Rael,

I found their website last weekend and it looks promising. I downloaded the trial, it's easy to use and the performance is good. I think I will go for it. I just hope their components will stay long in business :-)
They also offer 50% discount when migrating from another component suite.
I will look for that wizard.

thanks !!

Rael Bauer wrote:
I suggest you look at the devart.com components. I know that their
UniDAC has a migration wizard for FIBPlus, I assume their IBDAC also does...

-Rael
Rael Bauer

Posts: 228
Registered: 10/10/02
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 22, 2014 3:10 AM   in response to: Nico Callewaert in response to: Nico Callewaert
On 2014/09/22 08:47 AM, Nico Callewaert wrote:
They also offer 50% discount when migrating from another component suite.

Yes, that would be a big plus for you!
Nico Callewaert

Posts: 22
Registered: 5/9/02
Re: How to avoid maintenance nightmare with discontinued components  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 21, 2014 11:48 PM   in response to: Nico Callewaert in response to: Nico Callewaert
A big thank you to everybody for tips and help !!!
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02