Over the last few days we have seen random access violations being raised on Delphi 2006 using the ClientDataSet when loading an XML block but the errors disappear when using CodeGear 2007 rad Studio.
I have a strange feeling that this is going to come back and haunt us in the future.
So, how can I debug the xml load procedure for a clientdataset.LoadFromStream method?
I can see it is defined in dbclient.pas but I cannot seem to find the xml processing section.
JD
I don't know if you've tried this already, but it's entirely legal (and supported) to use the Delphi 2007 version of midas.dll with a Delphi 2006 application. Since Embarcadero did fix some DataSnap bugs in Delphi 2007, there is some possibility that the errors you are seeing are caused by a Delphi 2006 bug. It is worth a try to substitute the 2007 version of midas.dll with your Delphi 2006 application and see if the errors go away. It might not fix the problem, but it will save you a lot of trouble and frustration if it does.
it been a while since ive been on 2006 but if i remember right
turn on debug packages then you should just be able to step into it
As far as I know the LoadFromStream cannot be used to load XML files, the data in the stream should be in the internal format used by the client dataset. Try setting the XMLData property instead.
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.
Recently we upgraded our code from Delphi 2009 to Delphi XE and updated our Indy components (not sure if this is relevant).
But ever since then we have had errors on Windows Server 2003 machines when loading and saving XML files.
XMLDoc.LoadFromFile()
XMLDoc.SaveToFile()
The DLL msvcrt.dll is much smaller on Windows Server 2003 (300kb or so) compared to over 600kb on other operating systems... So its missing something in that file and its causing the error...
Does anyone know how to fix this? Or is there an alternative to TXMLDocument that I can try?
By default, TXMLDocument/IXMLDocument is just a wrapper around the MSXML COM interfaces when running on Windows platforms. Neither TXMLDocument nor Indy use the _ftol2_sse() function, or even link to msvcrt.dll. Something else in your project is at fault.
msvcrt.dll is (part of) the Microsoft Visual C++ Runtime. I think you got an older (or maybe even newer) version of this runtime that doesn't include this function.
Now you'll have to find out where this function is called. Do you link obj files with your project or use (other) 3rd party dll's?
To answer the last part ("is there an alternative?"), you might want to check out Jedi Code Library's TJclSimpleXML class. It does not require any external DLL, is quite fast, and is very easy to use. Besides, these days JCL and JVCL are a must-have anyway if you code in Delphi.
http://wiki.delphi-jedi.org/wiki/JEDI_Code_Library is their page I believe. I hear in seattle you can get it through IDEs integrated package manager.
Has anybody used/converted "Delphi Fundamentals" in Delphi 2009? - http://fundementals.sourceforge.net/
I'm using Dictionaries (cArrays.pas,cDictionaries.pas,cStrings.pas,cTypes.pas) in my project and now i have some troubles on upgrading code.
I'll be highly obliged if anybody can convert the above mentioned units in Delphi 2009. I'm quite new to Delphi, started working with 2007 and 2009 has been released, I just cannot help myself...
Thank you
I use cUtils, cDateTime and cStrings in a project.
After a 30 minute session of searching and replacing like a madman I got them to compile in Delphi 2009, with just a couple of warnings left to fix.
Char>>>>AnsiChar
String>>>>AnsiString
PChar>>>>PAnsiChar
PString>>>>PAnsiString
It passes all of its selftests, and so far things seem to work fine. I've shared it here: http://www.xs4all.nl/~niff/Fundamentals_UtilsD2009.zip
Update
I've added a ported cDataStructs.pas to the zipfile, which contains the dictionary classes. This one still has a lot of compiler warnings that you might want to fix, but the self-tests pass, so you could try and see if it works for you..
There is no official version of Delphi Fundamentals for D2009 (and I think there never will be any).
I think it would be the best option to rewrite the dictionary code using the Delphi-native TDictionary<TKey,TValue> class inside Generics.Collections.pas, or using the delphilhlplib (Collections/DeHL.Collections.Dictionary.pas).
I used to work in Delphi 6, and got very used to having CodeRush's various helpful IDE additions. Many are now in the IDE itself, or I've managed to replace with something else, but the one feature I REGULARLY find myself wishing I had in Delphi 2007 still, is the ability CodeRush had that added little "connecting lines" between components that were linked to each other (lines showing the connections between TDataSets and TDataSources, for instance).
Does anyone make something that does that in the newer Delphi IDE?
=== * LATER NOTE / Clarification * ===
Andreas is correct in his comments below... "I don't think that he meant structural highlighting which works on the source code. He wants "connection lines" between components in the form designer."
He also says "as far as I know there is no such tool for Delphi 2005 or newer".. which is a bummer if true. (...and if that IS the case, what's the best place to make Delphi IDE feature requests?)
I don't think it exists. The best place to make form designer feature requests is here.
another freeware/opensource option would be to look at CNPack which supports structural highlighting and runs well in Delphi 2009. The library contains many other enhancements to the IDE also, some which are duplicated in other packages such as GExperts. I run both CNPack and GExperts in both 2009 and 2006 without any problems.
You want Castalia, which works fine here on my D2007 for structural highlighting.
Castalia from Twodesk
Why is there an Indy9 folder (The default install folder of C:\Program Files\CodeGear\RAD Studio\6.0\source\Indy contains subdirectories for "Indy9" and "Indy10") Why are both versions installed? What is using Indy9? I didn't think it had been updated for 2009...is Indy9 now safe to use with Delphi 2009?
There is an opened QC report about this, but it's only visible to QC sysops.
The status of "open" typically means that it's accepted that this is a bug, rather than by design.
Remy Lebeau - one of the Indy developers - said this:
The 2009 installer does ship with the
Indy 9 source code, but it is not
selectable during install. There is a
note in the documentation that Indy 9
can be installed manually if needed.
But keep in mind that Indy 9 has not
been updated to actually support 2009.
At the moment, I am not sure if it
will be.
There are some changes in Indy 9 (from the 2007 version) so that it will compile under Delphi 2009 (a few String to AnsiString changes), but based on my tests it doesn't work. It tries to, but does not connect. If you want I can give you the changes that have been added for Unicode support, but I don't believe they are sufficient.
I can't really answer why. I could conjecture a few reasons, but I do not have any insider information.
Is it safe to use? YMMV. There is a lot to Indy, so there may be some parts that work fine for your project. Even a simple test with the TIdTCPClient resulted in Socket Error #11004 every time. Same for TIdHTTP. It seems like I tried the MD5 previously and it just got garbage, but I am not sure on that one.
Answer: It was included by mistake (assumption), and it is not safe to use (based on limited tests).
That is unfortunate, because Indy 10 has issues too, and I have some legacy apps that use Indy 9.
Indy9 is there for compatibility. There were some breaking changes in Indy10 (your code that was written against Indy9 may not compile under Indy10) so you have the option of continuing to use Indy9 (I think the installer prompts and asks what Indy you want to use - at least it did with D2007).
Update: Okay a few people have correctly commented that Indy9 wont compile with D2009 (because of the new Unicode support), so I guess I don't know why it is there.
My guess, it was in the source tree, and was automatically included by installer.
Keep in mind that the source files are not used unless you tell Delphi to recompile them.
If you do not have the Enterprise version you will not even have these folders.