I have a dll written in D6 Ent. that assigns an xmltransformation's data to
a clientdataset:
Clientdataset1.XMLData := XMLTransform1.Data;
This works great on my computer.
When another person copies the dll to their computer and makes a call to the
function where the above code exists, it blows up on that line with the
following message:
"DOMException with message 'Microsoft MSXML is not installed'"
We both have the same version of MSXML registered. What could be the
problem?
Is registering MSMXL different than having MSXML 'installed'?
Really, really hope someone can help. Thanks in advance.
Do you use some extensions which require MSXML3.DLL or MSXML4.DLL?
Regards from Germany
Franz-Leo
Yes and no. It is not "registered" in the sense that you signed up with
Microsoft to receive spam for the rest of your days-- it means all of the
registry keys have been added. You need to create all of these keys by hand
if you copy the DLL-- or you need to just install it. The best option is to
run the Install. BTW, did you install MSXML3.DLL or MSXML4.DLL? I think that
the current Delphi 6 classes utilize 3.
Regards,
Jeff Rafter
Defined Systems
http://www.defined.net
XML Development and Developer Web Hosting
BTY, I did Regsvr32 MSXML3.DLL and Regsvr32 MSXML.DLL but that didn't change
anything.
I just found the problem in the documentation for the Delphi Ent 6.01 Patch
that was rescinded by Borland because it was hosed.
Defect # 114567:
"'MSXML is not installed' is a error that may be raised even if the MSXML
dll has been installed. For instance if CoInitialize has not been called the
above error will surface."
Actually, it all works fine on my computer but the not on any other.
Others have received both errors - 'MSXML is not installed' and 'Failure to
CoInitialize' so it appears I'm dead in the water until Borland reissues the
patch in an 'non-hosed' state (soon I hope). Thanks so much for responding
though.
Carl
"Jeff Rafter" <.jeffr...@defined.net> wrote in message
news:3bb9ad93_1@dnews...
> I just found the problem in the documentation for the Delphi Ent 6.01
Patch
> that was rescinded by Borland because it was hosed.
> Defect # 114567:
Wow, thanks for the update-- that is a good piece of information to know...
-Jeff
If you want to narrow down the problem you can replace the following function in
your copy of msxmldom.pas and compile it into the application. Then it should
hopefully give you the true reason it fails on the second machine.
function TryObjectCreate(const GuidList: array of TGuid): IUnknown;
var
I: Integer;
Status: HResult;
begin
for I := Low(GuidList) to High(GuidList) do
begin
Status := CoCreateInstance(GuidList[I], nil, CLSCTX_INPROC_SERVER or
CLSCTX_LOCAL_SERVER, IDispatch, Result);
if Status = S_OK then Break;
if Status <> REGDB_E_CLASSNOTREG then
OleCheck(Status);
end;
end;
HTH,
Mark
The XMLTransformation that was used to load data into a clientdataset was
working before the patch but now it is broken because it no longer loads any
data into the clientdataset.
Also..I created a transformation with the original XML mapper that worked.
Just as a check, I tried the new mapper and now it won't create the same
transformation.
This is TRULY disheartening, a bummer, a software release holdup, and a
disturbing scenario to associate with Borland because they are normally so
meticulous. Have they been hiring ex-MicroSoft employees? ; ).
Hope someone at Borland is reading this and fixes the patch again.
Thanks
"Mark Edington (Borland)" <medi...@nolunchmeat.com> wrote in message
news:3bbb5a19_2@dnews...
If you could post a sample of the xml that you are trying to convert to a
clientdataset I will look at it and see if I can identify the problem.
- Doug
Doug Chapman wrote in message <3BC1D040...@nospam.com>...
For production the DLL is called from a D6 web app/dll. It returns the
error above whether MSXMLDOM is in the USES clause or not. Any ideas of how
to proceed from here? Getting desparate.
Thanks Mark (or anyone reading this) for any help you can provide.
P.S. Developing without the patch as no data is loaded into the
clientdatasets from the xmltransformation/xmldocument when the patch is
installed.
Carl
Mark Edington (Borland) wrote in message
It is the responsibility of the host .exe to call CoInitialize when it uses code
in a DLL that requires COM services. In the Delphi RTL, this is taken care of
for you automatically by code in the ComObj unit. The msxmldom unit uses
ComObj, so that is why including it in your uses clause fixes the problem. You
could replace this with ComObj instead and that should take care of it.
> For production the DLL is called from a D6 web app/dll. It returns the
> error above whether MSXMLDOM is in the USES clause or not. Any ideas of how
> to proceed from here? Getting desparate.
What kind of web app/dll? How is the DLL loaded/used exactly? If you are using
the DLL under IIS or some other Web Server then CoInitialize should have already
been called. However, you also need to watch out if you are creating your own
threads which use the code in this DLL, if you do, you need to "manually" call
CoInitialize/CoUnitialize in each thread yourself.
> P.S. Developing without the patch as no data is loaded into the
> clientdatasets from the xmltransformation/xmldocument when the patch is
> installed.
If you can get the files to Doug we'll verify the problem. So far he has been
unable to reproduce the problem.
Mark
Doug Chapman wrote in message
Carl
If you could post a sample of the xml that you are trying to convert to
a clientdataset I will look at it and see if I can identify the problem.
Doug
It is loaded in the Web app with the following declaration:
function CDLISCheck(ID, Password, TransType, State, License, LastName,
FirstName, DOB : string) : string; stdcall;
external 'CDLIS_VEH.dll';
It is called with a web page button click:GetXMLResult :=
CDLISCheck(ID.text,PassWord.text,TransType,State.text,License.text,
Last.Text, First.text, DOB.text);
CDLISCheck dll sucessfully gets the xml file into a string through the idhttp
component. But when the following code is run:
XMLTransform1.SourceXml := xmlstream; //xmlstream defined as string.
XMLTransformProvider1.XMLDataFile := xmlstream;
Clientdataset1.XMLData := XMLTransform1.Data;..the last line returns the
CoIntilization error (but only when called from the web app. Test.exe works
fine.)*Mark wrote:
* If you are using the DLL under IIS or some other Web Server then CoInitialize
should *have already been called. However, you also need to watch out if you are
creating your *own threads which use the code in this DLL, if you do, you need to
"manually" call
*CoInitialize/CoUnitialize in each thread yourself.
IIS is being used. How do you "manually" call CoInitialize/CoUnitialize in each
thread yourself? What is it that is being CoInitialized?*Mark wrote:
*If you can get the files to Doug we'll verify the problem. So far he has been
*unable to reproduce the problem.
Mark,
Posted reply to Doug telling I put files in Borland.public.attachments.
Thanks for all your help so far.
Carl
> *What kind of web app/dll? How is the DLL loaded/used exactly?Mark,
> Not sure what you mean by 'What kind of web app/dll?'. It was built (by
another
> developer) with D6 Ent using components from the Internet tab components.
I'm trying to figure out if this a CGI or ISAPI server and how the DLL question
is used in that context. So from what you've said, I gather you have an ISAPI
server that is statically linking to the second DLL in question. Is that right?
That being the case, you shouldn't need to call CoInitialize yourself. If the
server is a CGI executable, then just make sure that it contains a call to
Application.Initialize in the project source. That's where CoInitialize gets
called.
> IIS is being used. How do you "manually" call CoInitialize/CoUnitialize in
each
> thread yourself? What is it that is being CoInitialized?
If you are using TThread, then you'd put the calls in a try/finally block of the
Execute method of you derived TThread class. The CoInitialize call is required
for each thread that uses COM objects.
Mark
If you are using TThread....
**********
Mark,
You gather correctly. And TThread is not being used. From what you said,
the ISAPI shouldn't have to call CoInitialize...yet, we get the 'CoInitializtion has
not been called' error. That being the case, what should we do? Try calling
CoInitialize?
Nothing in help about CoUnitialize. I assume that CoInitialize is called with
Application.Initialize. Is that correct? Then how is CoUnitialize called and when?
Thanks
Carl
Ok, I just went through a bunch of messages on the
borland.public.delphi.internet.isapi-webbroker
forum and to be quite honest I'm more confused than ever. I've always been
under the impression that with IIS CoInitialize has always been called for you,
but now I'm not sure. Some of the messages I read seem to indicate there is a
difference between IIS 4 and IIS 5, which one are you using? I tested with
Win2K server and I certainly didn't need to call CoInitialize in my simple web
server application (that used TXMLDocument). The messages I read seem to
indicate that it's with IIS 4 where you need to make the call, but again I can't
say for sure.
I would encourage you to goto google and do search like this one (sorry but the
link will wrap):
http://groups.google.com/groups?q=CoInitialize+IIS&hl=en&btnG=Google+Search&meta
=group%3Dborland.public.delphi.internet.isapi-webbroker
The first thread there talks quite a bit about where to put the calls to
CoInitialize but no one seems to agree on what is "right".
I will do some more research and if I can find anything more definitive for you
I'll report back. In the meantime I suggest going with the calls in the
BeforeDispatch/AfterDispatch events to start.
> Nothing in help about CoUnitialize. I assume that CoInitialize is called
with
> Application.Initialize. Is that correct? Then how is CoUnitialize called and
when?
Yes, but only for an .exe, not a .dll. CoInitialize is called in an .exe as
part of a special exit proc.
Let me know about your IIS version and if you want I can send you the little
test application I wrote so we can see if it executes properly for you. There
may well be configuration issues that affect the behavior as well.
Mark
Mark said: Yes, but only for an .exe, not a .dll. CoInitialize is called
in an .exe as part of a special exit proc. I suggest going with the calls
in the BeforeDispatch/AfterDispatch events to start.
Mark,
Read all of the threads in the google link and I am still very unclear as
to how to make the calls.
One person said to call CoInitializeEx(nil, COINIT_MULTITHREADED)
or CoInitializeEx(nil, COINIT_SPEED_OVER_MEMORY);
Using COINIT_MULTITHREADED or COINIT_SPEED_OVER_MEMORY
gives a syntax error of 'undeclared identifier';
CoInitializeEx(nil,0); compile okay though.
Another person said call CoInitialize(nil);
That also gives a syntax error of 'undeclared identifier' as does
CoUnInitialize. So how do I really call it????
Mark said:
Let me know about your IIS version and if you want I can send you the little
test application I wrote so we can see if it executes properly for you.
Mark,
In development, I am using OmniServer and the other developer is using PWS
3.0.
The production server is using IIS 4 though we can put whichever version (4
or 5) on it.
Yes, please do send your test app and I will try it on PWS, OMNI and IIS 4.
I'm about to put the ISAPI and the DLL (that currently blows-up with PWS and
OMNI)
on the server that has IIS4 for testin.
Going crazy with this. Didn't realize how tangled this was going to be!
Thanks for your help Mark,
Carl
> Mark said: Yes, but only for an .exe, not a .dll. CoInitialize is called
> in an .exe as part of a special exit proc. I suggest going with the calls
> in the BeforeDispatch/AfterDispatch events to start.
"CoInitialize" in the second sentance above should have been "CoUninitialize",
but I assume you figured that out. I wasn't clear as to why you quoted yourself
and me again in the message.
> gives a syntax error of 'undeclared identifier';
Ah, you'll need to add "ActiveX" to your uses clause for that one...
> The production server is using IIS 4 though we can put whichever version (4
> or 5) on it.
If you have access to a machine currently running IIS5, I would be very
interested to know if you application runs correctly without doing any
CoInitialize.
> Yes, please do send your test app and I will try it on PWS, OMNI and IIS 4.
I emailed it to you.
Good Luck!
Mark
Thanks, that's what I needed to know! App runs flawlessly (so far).
Also tried a different approach where CoInit isn't required. Instead
of turning the DataModule into a dll, i just used it as is and have ISAPI
create it at run-time. That method also runs flawlessly (so far).
> If you have access to a machine currently running IIS5, I would be very
> interested to know if you application runs correctly without doing any
> CoInitialize.
Will look for someone in the office with Win2000.
> > Yes, please do send your test >
> I emailed it to you.
App wasn't relavent in this case because the CoInitialization error I was
getting didn't occur in the dll until trying to assign the transformation
data to a
clientdataset.
Clientdataset1.XMLData := XMLTransform1.Data;
Thanks though and thanks SO, SO MUCH for the help!
Now I have to deal with the prob I mentioned in an earlier part of this
thread.
(Doug may be looking into it - no response yet).
The XMLTransformation that is used to load data into a clientdataset works
if I don't install the patch but when I apply the patch it no longer loads
any
data into the clientdataset.
Wish me luck,
Carl
Yes sir.. the patch is majorly hosed regarding the above line and the 'NEW'
xmlmapper still can't be used to create a useable data file for the xml I
have.
That part of the unpatched version of D6 did worked.
Doug, did you ever try to verify what I am saying with the xml file I
sent you?
Carl
Resolution :
1. Save copy of original D6 folder/subfolders.
2. Apply the D6 patch.
3. Copy xmlutil.pas and xmlxform.pas from original D6\Source folder
to project folder.
4. Recompile the project.
It now works correctly (again)!
Borland: It appears that those two files need to be revisited.
Thanks All. Hope this info helps someone.
Carl
> Yes sir.. the patch is majorly hosed regarding the above line and the 'NEW'
> xmlmapper still can't be used to create a useable data file for the xml I
> have.
> That part of the unpatched version of D6 did worked.
>
> Doug, did you ever try to verify what I am saying with the xml file I
> sent you?
Carl, I was out all of last week and I'm still trying to catch up on things
here. I checked with Doug and for some reason he never got the file you sent.
Would you mind resending it directly to me? Just replace "nolunchmeat" in my
replyto address with "borland". I'll check it out right away and get back to
you.
Thanks,
Mark