2

I'm migrating a large family of applications having hardwired FIB+ connectivity inside to Fire-Dac components and I'm looking for some least painfull way, how to do it.

First, I've decoupled and migrated the backend to get connectivity neutral and connectivity dependend parts and refactored existing applications manually. I've written FireDac parts as well.

To migrate Delphi code it seems to be no problem...

But big pain in the ass seems to be a migration of components placed on forms and data modules in design time: I installed GExpert and tried its command Replace Components with defined rules how to map some properties, but it lost mutual reference between components, probably due type incompatibility in step-by-step replacing process.

My current approach is hand job: to add a suffix to the name of old FIB+ component, copy&paste original name to new corresponding Fire-Dac component. This step I repeat for all components, then set properties properly and drop FIB+ components. It allows me to inspect old setting again and again during this process.

Does anybody has some proven/recommended way how to do it better?

Thanks, pf

pf1957
  • 997
  • 1
  • 5
  • 20
  • Voted to close as not constructive because this question will definitely lead to debate. – Jerry Dodge May 18 '13 at 05:31
  • 2
    I see: questions which can be googled out, read in help, MSDN, Wikipedia, source code or gotten from another resource are allowed only... – pf1957 May 18 '13 at 06:35
  • Not necessarily, although partially true. My point was that people will give their opinions of what they think is the "best" solution, and could stir up people arguing. – Jerry Dodge May 18 '13 at 06:37
  • As most painless step about design time components seems to me replace class types in *.dfm files. – TLama May 18 '13 at 07:30
  • 1
    I'm afraid that I'd fall into design time hell, where it is not possible to open form designer until .DFM is valid. Unfortunatelly, to change a type or simple property is not enough: e.g. FIB+ dataset has property for each SQL operation: select, refresh, insert, update, delete, but Any-Dac just a single SQL property -> the substitution requires to introduce UpdateObject into form etc... Anyway, I'll try it - perhaps copy&paste definition of UpdateObject. – pf1957 May 18 '13 at 07:54
  • I see that this question may be open to debate, but there's also a real question - i.e., is there a painless way to do this? (for example, a tool.) – Leonardo Herrera May 18 '13 at 15:23
  • @pf1957 was trying to work out how to message you on SO as I am a newbie. An additional comment on this is .DFMs or rather component streaming only generally stores values that differ from the defaults. FIBPlus had/has a number of IDE add-ins / editors etc and possibly some less than efficient code that means that a lot of your developers "default settings" end up in the DFM, eventhough they are identical in every instance of your T??field, TpfibDataset etc. These generate fog and in fact I think for my project I have redundant insert/up/del statements- If you are still on this, reply here. – Jason Chapman Aug 22 '20 at 18:28

1 Answers1

3

Several aspects:

  1. If you are using properties for different SQL operations, then you can derive TMyQuery from FireDAC TADQuery. TMyQuery will create TADUpdateSQL and publish it XxxxSQL properties in TMyQuery interface. Also, you can introduce in TMyQuery other FIBPlus properties and methods, missed in FireDAC TADQuery.
  2. The similar approach you can use for other FIBPlus components to achieve high compatibility level between FireDAC and FIBPlus.
  3. You can use FireDAC addon tool - ADDFMChanger, to automate PAS / DFM migration from FIBPlus to FireDAC. The setup and migration then will be similar to BDE -> FireDAC migration. FireDAC / AnyDAC addons you can download from da-soft.com.
  4. The major migration issue may be difference in FireDAC / FIBPlus behaviours. I cannot comment here, because I have no experience with FIBPlus.
da-soft
  • 7,670
  • 28
  • 36
  • ad 1,2) It is an interesting idea, because I've interposed a "layer" between FireDac and application anyway. ad 3) I used your tool already, but currently with no success (similary to other replacing tools like GExpert, GReplace) - perhaps after applying your idea to emulate FIB+ interace, those 1:1 mapping tools will be usefull. ad 4) I did basic tests with Any-Dac trial before and it seems there should not be a problem. – pf1957 May 19 '13 at 14:21
  • (3) "with no success" - hard to say something without info. Anyway, it seems after applying (1) and (2) you should not have problems with a "draft" migration. But then you should be ready for (4), as there *will be the differences*. – da-soft May 19 '13 at 15:10
  • ad (3) it is not related to AD changer functionality, but to FIB+ -> FireDac migration per se and I didn't provide a details intentionaly as irelevant. But one thing could be IMHO useful: a rule to drop a property from .dfm: I tried [something] -> [] -> [], but it replaces original name literally by blank name. – pf1957 May 19 '13 at 15:27
  • (3) Thank you for note, we will check that. – da-soft May 19 '13 at 16:01
  • Finally, I've used your advise (1) to encapsulate update object into my TADQuery descendant and ADDFMChanger.exe with my set of rules to migrate sources. This way I've beaten down the Delphi design-time and the rest is the same as task as migrating ordinary code. Thanks. – pf1957 Jun 06 '13 at 19:19
  • @pf1957 so were you successful? I am about to migrate 2 x D7 BDE + FIB -> FireDAC and looking for some automation? Trying to use The Delphi Parser, but stumbling with the scripting requirements. Also Refind doesn't give the depth I need. I like the interposer, but but means you end up with what must be some ugly getters and setters. Would be interested in getting your experience. – Jason Chapman Aug 21 '20 at 17:19
  • @Jason Chapman Sorry for being late with my response. I'm retired and I spent minimum time with programming stuff... Answer is yes, I was sucessful. I migrated .dfm files via ADDFMChanger.exe, .pas files using sync edit mode. I wrote proprietary internal dox of this migration, unfortunately for you in Czech language. – pf1957 Sep 23 '20 at 18:16
  • @pf1957 thanks for taking the time to reply and I hope you are enjoying retirement. If you have anything I could use (in any language) including the addFMChanger.exe script. No worries if you can't, but I am sure I could use them to map. Cheers JAC. – Jason Chapman Sep 25 '20 at 16:06