Delphi : Migration from Paradox/Bde to MYSQL5.x

Sorry to submit the same question again, but I am in desperate need of help
My company has many applications written in Delphi 2007 using paradox and bde.
Initially I was going to convert the code and use MYSQL 5.x but the company decided to migrate from Delphi to C# connecting to MYSQL on a remote Linux server
This project has stagnated and hence I have been asked to review the Delphi code as a short term solution
Please can somebody recommend the efficient method to do this, I assume I will have to replace in the code where I use tquery commands to view / add/delete/ edit tables which is going to time consuming
One of the main points will the option connect to MYSQL on a remote Linux server as well a local server
Who is Participating?

Improve company productivity with a Business Account.Sign Up

epasquierConnect With a Mentor Commented:
Ah, the good old Delphi to C# projects...

I can't understand why a company having loads of Delphi legacy application would want to convert to C#.
I know the argument that there are much more low-cost developers available in C# than Delphi, but I would say that any good C# developer can learn Delphi in much less time and cost than the bunch necessary to rewrite the application(s).
And developers that cannot learn Delphi are not worth the effort anyway, even with a managed language they will most certainly create more bugs than features.
But that is so with deciders that do not want to invest in their people, and only follow the roads taken by the vast majority, and the cold feet saying MS is a more secure investment.

That said, my bad mood about this sensible issue being a bit quietened :
* BDE is deprecated since a very long time (even at the time of D2007, so it was already a bad choice)
* I will not even talk about Paradox, that is so old and deprecated that it has a list of issues with modern OS that would

So yes, there is a real need to change DB choices for these applications (But that certainly doesn't mean the language, Delphi, has to be changed). What can you do :

* ADO is a not so bad choice, it can work easily with all kind of server, located anywhere, with just a connection string to input as parameter (put it in INI file). Most of the code of your application should work the same after that, except for particular SQL functions that can differ from one DB to the other (try to avoid specific SQL)
But ADO is not very efficient. Of course, compared to Paradox+BDE, what an improvement it will be.....

* DBExpress : lots of pro and con about it. Some says it's not as good as ADO because of a restricted feature tests, but those are mostly old saying - ADO didn't changed much since 5, while DBx never stopped adding nice features. That is what they say, I never used it myself.

* Now, let's talk about the SERIOUS alternative, but that involve some political choice from the same guys that decided to go to C# : DevArt components @
DevArt is the White Wolf as far as DB connectivity is concerned : they have a very complete set of native connectivity for all DB. Ultra fast, efficient, feature set complete, and not too expensive. You can either BUY one component set specific to ONE DB - like ODAC (Oracle Data Access Components), or BUY the complete UniDAC huge set that will allow complete independence of the DB, and keeping very good performances nevertheless.
Well, in your case, I would go for MyDAC (MySQL DAC) , only 200$ for a single user licence in Pro version. And better prices for multi user licence of course.

If you can convince your boss that your time is worth 200$ of components set, then you have your best option. And maybe, when he will see the result, he will also decide to stick to Delphi....
ADO has a lot more flexibility to switch to mssql/mysql/odbc/ole
SSSIANAuthor Commented:
To epasquier
Thank you for your rant and useful advise, if I converted to MyDac, would if be painfull task of replacing all calls via tquery / ttable and query commands
I did think about using this before, but on investigation there seemed to be lot of code change

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

you cannot avoid a bit of work. But, if your code is well written, you don't have much dynamically generated SQL, it should remain fairly untouched, beyond the initialization of the connection.

By well written, I mean you use Params instead of building the SQL text, you use fields variables added at design time instead of constantly access those with FieldByName at run time etc...

Replacing the components can be helped a lot by 'Replace Components' function in GExperts for example
I haven't tried it on TTable but it worked miracles with buttons and other standard components replaced by Jedi more advanced components, and I upgraded my interface in all my projects in seconds.
aikimarkConnect With a Mentor Commented:
I'll defer to epasquier on the specifics, but I think the only sane path would be to get the data into MySQL and upgrade the Delphi application to access the data.

Then look at a more current version of Delphi that can create .Net applications using Prism (VS IDE).  Once you have a .Net application, look at one of the .Net language translators that express an assembly in any given language -- select C# as the output.  I don't expect that the C# code will be pretty, but it is a starting point for the Delphi-to-C# migration.  You would transfer comments and variable/property/function names from Delphi to the C# code.

In general, I agree with epasquier's assertion that a language conversion (for conversion's sake) doesn't make sense.
SSSIANAuthor Commented:
Thank you for confiming the solution already had in mind
aikimark, if you were not so valuable to this community, I should hire assassins for your explaining how to migrate 'easily' from Delphi to .Net.
Another thing that saves you is that, while I haven't done it myself just in case I loose my soul in the process, I'm confident that it is not so easy to create the .Net application (even using Delphi language) if the code has not been very well written or is using too much specific code.
After that, sure, language translation is a great feature of .Net. But I would leave that easy part of the work to the next poor guy maintaining the project that doesn't understand Delphi syntax and need to makes his brain sorry reading poor unreadable C syntax.
(Never loose an occasion to resist if it's cheap)

I didn't mean to infer that a Delphi-to-C# code migration would be easy or painless.  The source code produced from the assembly is (will be) ugly, possibly bordering on fugly.  The best way to stop such a task is to go through the steps to produce some C# code from some non-trivial Delphi program and show management the work that will need to be done to transform the C# code into a maintainable code base, suitable for production.

>>if you were not so valuable to this community
Thank you for that kind thought (and not calling out any assassins)
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.