I have an old application running BDE under Delphi 7, and have now bought Delphi XE. Can I expect big problems if I try to stick with BDE under Delphi XE? Or will converting save me time in the end?
Issue 2: I have seen some people trying to use the included Installaware installer to install BDE and a database alias etc, but I am not sure if anyone succeeded. Is it possible?
Rgds PM
As long as you stick to 32 bit applications, it will work. There is no BDE for 64 bit.
But as everybody and his mother will point out: The BDE has been deprecated years ago and sooner or later you will run into trouble. E.g. you might not be able to install it on Windows 7 or your customers might fail to do that.
We are currently in the process of moving away from it and it is a pain in the lower back because it has been used in so many utilities for too long and there isn't quite an alternative for it for accessing dbase tables.
Related
although the question might seem to be similar to other questions concerning this subject, I am afraid it is more complicated.
I try to run a program that I programmed a long time ago under win XP using Delphi 2005.
Now using Delphi 10.2.3 Toky, working with the same program, I get an error bdertl and intraweb 72 90 not found.
I simply deleted intraweb components.
When I also deleted bdertl the error remains.
In the program I use ADO compounds. I don't see any compound which might be from Paradox , BDE-
Can anyone help me to resolve the bdertl error?
Thanks
Thommy7571
Check if BDE/Intraweb related pas files are present in the uses list. For example Dbtables, bde.
We currently use D2007 but are considering an upgrade to XE2. I can think of two "bigger" issues here - the Unicode step from 2007 to 2009 and the whole platform stuff from XE to XE2 (32/64 bit, VCL/Firemonkey with pointer sizes, unit namespacing and whatnot).
AFAIK we also get D2009, D2010 and XE if we buy XE2, so my idea was to tackle the upgrade in two steps:
First deal with Unicode. I guess the best way to do this is to upgrade to XE: We would have working generics etc. but no additional issues compared to an upgrade 2007->2009.
If step 1 is done and has shown that it works for our customers do XE->XE2.
What do you think? Should we do the whole upgrade in one step instead ? Or two steps but with a different intermediate version?
Edit: I'm aware that XE2 doesn't force us to go cross-platform (FireMonkey probably never will be an option for us). I just want to avoid related issues like "XE2 values of mrAll, mrNoToAll, mrYesToAll and mrClose" while fighting any Unicode related problems. And unit namespacing sounds like quite a hindrance if we were to make our units compatible with both D2007 and XE2 during the transition (or is that a bad idea anyway?).
I would just jump straight to XE2. Just because it supports 64-bit and FireMonkey does not mean you have to use them right away. Just write 32-bit code first and do your Unicode updates as needed, but be mindful of 64-bit when dealing with pointers, memory usage, etc to minimize the need for future migrations when you are ready to tackle 64-bit. Don't even worry about FireMonkey, as that is a completely new framework, so you would be starting from scratch anyway when you make that jump.
I started occupational programming with Delphi when the Turbos came out , and have licenses for Delphi 2006 Turbo Pro and Delphi 2009 Professional. I have been asked to support another in-house tool, written by another occupational programmer, who has since retired.
It's a Windows program, but it was developed with Delphi 6 using the CLX library rather than the VCL.
From what I gather, the CLX library was QT based and was removed prior to Delphi 2006.The support only consists of a few bug fixes and some minor tweaks, so I would rather not port the code to VCL, if i can avoid it.
Is it possible to install CLX support into either Delphi 2006 or 2009?
Maybe not a direct answer but if you upgrade to Delphi XE, you will also get license keys for some of the older versions of Delphi down to 7, and Delphi 7 included CLX (it was dropped in Borland Delphi 2006).
The short answer is: no. Unfortunately I don't know any long answer which could tell you how to workaround this.
No, you can't add support for CLX to your other Delphi versions.
If it's in-house software, then your company should still have the in-house Delphi installation used to develop it. Multiple Delphi versions can co-exist on the same system; install earlier versions before installing later versions.
If the former employee took that installation with him when he left, can you get it back? I wouldn't expect it really belongs to him anyway. You said he retired; that wasn't a euphemism for died, was it? If not, then you can still contact him.
If there isn't an easy way (and I suspect that there is not), you may need to continue using D7. D2009 is going to introduce the hassle of Unicode, and even going to D2006 is going to cause problems with 3rd-party libraries.
You could run both versions of Delphi on the same machine, but another option would be to use a VM for the legacy development. Either set up a new instance, or you could use the VMWare Converter to convert the other developer's entire machine into a VM image, which you could run on your machine, via the free VMWare Player.
BTW, VMWare Converter is a GREAT way to preserve old environments, to allow maintenance on older software that really needs to use a particular Delphi version, on a particular OS, "just like I left it". If you have a bunch of dusty computers under your desk, consider this option. VMWare Converter is the only tool I know of that will easily convert a physical machine to a useable VM that will run anywhere.
From what I've read from the previous posts, Delphi 7 is stable and has the best help system but is slow, Delphi 2007 is fast but the help system is bad and the IDE is buggy. Delphi 2009 is stable and fast but the help system is bad too. The posts were made when 2010 isn't available yet. I am planning to upgrade from Delphi 7 to 2010. Is Delphi 2010 stable, fast and has a good help system?
Delphi 2010 is one of the best Delphi releases ever. It stabilizes some of the new features introduced in Delphi 2009. The IDE is fast, and in the project I used it was very stable.
The thing there is that the IDE and the help system are build as a RAD Studio for different languages. Especially the help system tries to be everything for everybody. Even having only one personality installed, it has many entires about other languages I do not care about (but I can filter them). Yet there are many entires missing depth that never made it into the new help format.
The help system starts painstakingly slow (especially at first startup). But, to be fair, this is partially do to the MS Help System being a pain in the neck (this, in my opinion, just was the wrong path to chose).
Embarcadero invests quite some effort into the help system, and it had several updates during the 2010 release.
You do know about the varying expense of conversion to Unicode as 2010 is fully Unicode based?
Here are some reasons why I stick to Delphi 7, having Delphi 2010 at hand to recompile and test what I wrote in Delphi 7, in a cross-version manner:
if your source code compiles on Delphi 7, and you make careful usage of Unicode/AnsiString, it will work as well with Delphi 2010;
if your source code compiles on Delphi 7, it will work as well with Free Pascal, so
cross-platform and 64 bits are open to you;
if your source code compiles on Delphi 7, it can be cross-compiled with CrossKylix directly from the Delphi 7 IDE - see Has any one used CrossKylix for real Cross-platform development?
Delphi 7 runs well on my Windows Seven 64 bits system, if you install it not in "C:\Program Files" but in "C:\Progs" for example;
Delphi 7 starts faster than Delphi 2007, and MUCH faster than Delphi 2009/2010 - see http://andy.jgknet.de/dspeedup
generated code is almost the same since Delphi 7 - when I need speed, I use better algorithms, and assembler if it's worth it;
Delphi 7 IDE is as powerful as Delphi 2010 IDE, if you use some IDE enhancements like http://www.cnpack.org;
Delphi 7 help is still the reference - why waiting for 20 seconds on my Core i7 processor waiting for the awful MS help system to launch? and if you want to create an application able to run under XP, its content will be enough for you; if you want to know about newer OS, just use msdn web site directly, or via google: it sounded to me easier than the help integrated with Delphi 2005/2010;
I use the assembler/CPU view a lot: all Delphi IDE have the Alt-F2, but you can close this window by the escape key on Delphi 7 - I was not able to find such a keyboard shortcut under Delphi 2007/2010, and it's very annoying;
Delphi 7 executable size are small, and even smaller with our LVCL libraries (30 KB for a form with buttons);
I didn't have the need for generics and such up to now - I like knowing which code is generated;
Delphi 7 is Unicode ready, whatever you say - its associated VCL was not, but CharSets are not evil, and work well - what I do is develop under Delphi 7, then compile with Delphi 2010 and get all the Unicode benefits if needed;
I use a large screen (at 1920x1280 resolution), and Delphi 7 makes it easy to have multiple edit windows at once - newer IDE locked layout was not a good idea... at such that EMB officially added the "Delphi 7 way undocked IDE" feature to Delphi 2010: and marketing sell it as a new feature;
and so on, and so on...
You can use Delphi 7 help in Delphi 2010, if you want to.
Use this or this addon. See item 5 here for instructions (sorry, it's machine auto-tranlation).
P.S. You can have more than one help installed. Say, a F1 for Delphi 7 help and Ctrl+F1 for Delphi 2010 help.
delphi 2010 is stable and fast and is actually a good delphi compiler after years of half-baked releases, they have improved help system in delphi 2010 but i still think delphi 7 help system is superior(but thats just my opinion).you do know delphi 2010 has a 1 month trial do you? download it and play around and see if you like it
EDIT: forgot to mention if you buy delphi 2010 you'll get marco cantu's Delphi 2010 Handbook for free ,the book covers whats new in D2010 so if you consider book as part of help system than help system is OK :)
Delphi7 was faster, but it was a lot simpler. I wouldn't worry too much about performance of the IDE, especially if you're working on a modern PC. At work I've got an old P4 machine, and it runs just fine.
New language features like methods on records and generics make it well worth it to switch.
For me it's hard to live without TList<T> nowadays.
For a while I've desperately tried to keep code Delphi7-compatible, but I've ported most of the important applications to D2010 already, and whenever I need to start D7, it all feels so low-tech and simple.
I've always hated the crappy component palette in the older Delphi's. Delphi 2010 has a much better interface, and the filter function is a real time-saver.
I've decided to give up on Delphi7 and just make full use of D2010's capabilities. That makes life a lot easier.
I am interested to re-evaluate Delphi 2010. The main issue seems to be the ascii to unicode conversion. Any tips or resources about this that you have found useful?
Many thanks.
Edit:
At this point my recommendation for those that want to upgrade would be:
http://www.embarcadero.com/images/dm/technical-papers/delphi-in-a-unicode-world-updated.pdf
Is WideString identical to String in Delphi 2009
What is the compiler version for Delphi 2010?
http://chee-yang.blogspot.com/2008/10/delphi-2009-unicode.html
GIF issues:
Note that Gif (by Melander) and Png (by Martijn Saly?) images are now incorporated in Delphi 2010. You will have to use a conditional in order to use the right GIF unit:
USES Windows, SysUtils, Graphics, blabla
{$IFDEF VER150}
, GIFImage, {Delphi 7}
{$ELSE}
GIFImg {Delphi 2010}
{$ENDIF};
Also you need to "fix" the PNG provided by Embarcadero:
http://talkdelphi.blogspot.com/2009_03_01_archive.html
Other things that you need to know is that you really have to backup your project before opening it in Delphi 2010. Delphi 2010 will change your DFM file even if you don't press the Save button. The form will lose data and it will not compile in D7.
UPDATE Delphi XE
I have finally purchased Delphi XE. Delphi XE proposes some new features but, unfortunately, quite few of them are not working at all (background compilation, UML modeling, code insight, etc). Other features have been downgraded (the help and, for example).
The IDE is also not as stable and fast as Delphi 7 and the toolbar has real problems (better don't customize the IDE). There is also a nasty bug where the IDE has 100% CPU utilization (see my other posts about all these issues).
I hope that in Update 2 and 3 they will fix some of the most stringent issues.
Anyway I think I upgraded too soon because now Embarcadero announced the 64 bit compiler, so probably I will have to pay again a lot of money to upgrade to the next version of Delphi in order to get that compiler. For those that are still thinking to upgrade to Delphi XE I would recommend to trial Delphi XE HEAVILY.
Conclusion:
Delphi XE brings LOTS of new features, but obviously you won't be using ALL of them.
The stability of the IDE is not better.
It helps you build more up to date applications (modern UI open/save dialog, application manifest).
Support for unicode.
UPDATE Delphi XE7
The difference between XE and XE7 was not that huge as the upgrade from Delphi 7 to XE. The IDE is as stable as before (lots of crashes and random access violations in RTL).
UPDATE Delphi Rio
Considering the amount ot years since the last update, I could safely say that the difference between XE7 and Rio is barely visible - except for those that are interested in cross platform apps (Mac, Android but not Linux!).
PROS
True high DPI support (really Embarcadero? After so many years?).
IDE does not crashes so often as it used to crash in XE7.
VCL themes finally (seem to) work.
Most stable IDE until now (still crashes if you open a project group with more than one project in it).
Almost full cross-platform support (you need to purchase the more expensive Architect version to get Linux). Fortunately, for me, this is a bit too late. The projects where I needed cross-platform were already started under Lazarus.
Upgrading the code was super easy.
CONS
Some HIGHLY advertised features like dark themes don't work at all!
The Insight still buggy: new language features (like declaring inline variables) not supported by the IDE (the code will have that wiggled underscore red lines). This issue will probably never be fixed.
Another super annoying IDE issue is that the compiler will still show the last hints/warnings/errors EVEN after you fixed them. Looks like the log data remains in some kind of cache.
Overall it is the most stable IDE until now, but still I wonder (especially if compared to Lazarus) if it worth that pile of money.
Conclusion over the years:
Delphi is such a nice and clean language. And the Delphi compiler speed makes any C++ compiler to look like a toy for kids.
I still feel ashamed people look down on me when I say that I am a Delphi developer. Delphi as a language is extinct now. Just look for Delphi jobs in Germany and only 74 positions are listed (but most of them are mixed with C# and others). C++ has over 1500 positions! Borland and Embarcadero helped a lot to kill Pascal. They do offer a free (even though crippled) version of Delphi now, but the damage was done. It is to late to resurrect Delphi now.
I think three main issues lead to this state:
Borland abandoned Delphi (Delphi lagged behind compared with other languages).
Embarcadero took over but disrespected the customers (over-buggy, over-expensive product).
MAIN ISSUE: The language was not promoted (at all) over the years. No sane company will spend thousands of dollars for a license of an already dying language. And the lack of a free license TOTALLY outcast the new generations of programmers.
Therefore, we are on StackOverflow, wondering each year if worth investing money in a new Delphi license.
Update
Finally, Emba released a free (aka Community) edition and boy you can see the effects.
For the first time in years, I don't feel ashamed to say in public that I am the user of Delphi (a dying language).
We have created a web page specifically for this very issue:
http://www.embarcadero.com/rad-in-action/migration-upgrade-center
There, you can find webpages, documents, webinar replays, etc. which all cover the issue of migration.
The first thing people say is "I have a huge codebase, and migrating to Unicode will take forever" and almost without exception they discover that "forever" really is a much shorter period of time than they originally thought and that the new features of Delphi 2010 make it all worth it.
The biggest problems are with 3rd-party libraries and VCL. If they're not on D2010, it can be painful. The Unicode issue comes up if you are doing calculations with the length of strings or PChar arrays, assuming one byte per character. You can usually get away with treating everything as old-style AnsiString / AnsiChar. But then you don't get the benefits of Unicode. If you don't have anything that would be hard to do in Unicode, just do everything in Unicode and you'll be much further ahead than if you have to worry about switching back and forth.
Converting code to unicode doesn't take that much time in itself as long as you didn't do anything "funny" with your strings. I converted close to 1m lines of code + the database in less than 2 weeks. The guys at codegear did a very good job at doing it a lot simpler.
Your code might recompile in D2010 without any changes (But with quite a few tons of hints/warnings).
The worst problem from the conversion comes from calls to Window's API that were incorrectly done. For exemple, the function GetComputerName that ask you the size of the buffer in TChars(as specified by the API). In Ansi, TChar = 1 byte, so Length = SizeOf. In Unicode, it's not true anymore. Worse, the call to the API might not fail. It will just overwrite some valid part of memory and will crash just much later.
Oh... And there is also those slight differences between Ansi and Unicode in Windows API. For exemple, the lpCommandLine of the CreateProcess is read-only in the Ansi version, but read/write in the unicode version. So using a constant as parameter worked fine in Ansi, but will crash in Kernel32.dll in Unicode.
Overall, it depends a lot on the quality of the code you are working with. Bad code might be very hard to port to D2010. Good code should be pretty easy.
and read the resources that Nick Hodges linked to, they are pretty helpful.
For Unicode conversion issues, your best bet to see the problems people have encountered and what others have done is to get Cary Jenson's White Paper: Delphi Unicode Migration for Mere Mortals.
Also I'd highly recommend Marco Cantu's "Delphi 2009 Handbook" that describes all the changes in the Major 2009 release that includes Unicode and Generics and more. Much of his Unicode material from that book is in his White Paper: Delphi and Unicode.
We have upgraded from Delphi 7 via Delphi 2007, 2009 and now 2010! The following are the biggest issues we have found.
Threads have changed, with Resume and Suspend being deprecated.
Unicode
The structure of projects have changed and are not backwards compatible
The structure of dfms have changed and are not backwards compatible
Hope this helps.
I agree with Chris - the biggest problem in migrating our code to 2010 was getting all of the 3rd party libraries working. A number of them needed minor source edits here and there and had to be installed from the modified source. Still, that said it wasn't more than a day or so of getting things sorted out.
The only other problem we've had moving to 2010 involved one small section of code that went buggy because of a change in the way 2010's ProcessMessages works. It was an old piece of code that probably shouldn't have been written the way it was to begin with (ProcessMessages and Sleep() inside a while loop waiting on an OPC variable change). It worked in 2007 but in 2010 it somehow devoured system messages and locked up the OPC server. For us it was a small fix, but like Ken said it will likely depend on the quality of code you are porting. 2010 seems a bit less tolerant of poor practice and ugly hacks.
View this Embarcadero webinar on how to migrate from older editions of Delphi with some stories of what to look for and how to update your code (including tools and resources to help you along the way), on this link: https://community.embarcadero.com/blogs/entry/migrating-delphi-case-studies