I'm having an issue trying to access a web service through Delphi. I've consumed a java WSDL with the 2007 version of the WSDLimp tool and it looks like it's created all of the objects correctly. When I make a tester program however that calls the service every object is empty. If I dump the SOAPResponse object in the HTTPRIOAfterExecute method I can see that I've gotten back a properly formatted XML Soap packet that contains all the data I would expect, but I can't access it through the objects. So is there something I'm missing?
The web service response contains aliased namespaces for each attribute. These aliases are not defined in the WSDL. For example, the WSDL contains a namespace of "http://www.example.com/SomeService" and the request aliases that on-the-fly as xmlns:ns3="http://www.example.com/SomeService" in the top level node. So attributes in the response look like ns3:somePropertyName="[value]".
In the OPToSOAPDomConv unit, in the TSOAPDomConv.InitObjectFromSOAP, it's attempting to look up an attribute name without the namespace prefix. This is causing the look up to fail and the object property to be left blank. This is happening even with the 2007 source files.
The best fix I can see is to modify the InitObjectFromSOAP routine.
Around line 4181, add:
RemTypeRegistry.InfoToURI(PropList[i].PropType^, NS, PropName, IsScalar);
and change the AttrNode.HasAttribute to pass the NS variable as a second parameter so it looks like:
if AttrNode.HasAttribute(ExternalPropName, NS) then
Also, a few lines down is a SetObjectPropFromText call. The last parameter is the attribute value, and you'll need to change Attr.Attributes[ExternalPropName] to
SetObjectPropFromText(Instance, PropList[I], AttrNode.GetAttributeNS(ExternalPropName, NS))
And of course declare the NS, PropName and IsScalar vars.
Delphi dropped the ball on web service support after Delphi 7 and didn't get their act together again until Delphi 2007 (though 2006 was an improvement).
If it works for you in Delphi 2007, you can probably get this working in Delphi 2005 by using the updated SOAP runtime.
http://cc.embarcadero.com/Item/24535
You could try the solution discussed at http://www.borlandtalk.com/1-vt102378.html?start=0
I re-read the question and the fact that it's a Java web service made me remember something.
Making sure you use the latest WSDLImp and SOAP units. Look in the imported unit for the call to RegisterInvokeOptions. The second parameter should be ioDocument. What happens if you change this to ioDefault.
I remember a post somewhere that suggested this for Java NetBeans (maybe?) web services, but haven't tried it.
Related
When creating a new Windows Service in Delphi, it inserts the following:
if not Application.DelayInitialize or Application.Installing then
Application.Initialize;
The author didn't bother including parentheses, so I'm trying to wrap my head around this. It translates to:
if (not Application.DelayInitialize) or Application.Installing then
Application.Initialize;
From what I understand, if both Application.DelayInitialize and Application.Installing are True, then it will go ahead and Initialize the service application. I don't understand why it would be initialized in this scenario - I'm pretty sure it shouldn't be initialized.
Can someone give me some clarification what I'm looking at here?
On a side note, I would never need to enable DelayInitialize as there's no need to be concerned with Server 2003. I would just like to understand what this code is actually meant to do the way it's written.
As the comment inserted in the project source when you create a service application explains, DelayInitialize exists for a specific reason: the requirement to call StartServiceCtrlDispatcher before CoRegisterClassObject. Whether you would need to set it or not, I presume, would really depend on if you need to call CoRegisterClassObject, not if you're targeting server 2003 or not (*). IOW, I wouldn't expect that comment to be updated with every new server version. YMMV, testing might be required.
The implied design here is that you use System.InitProc to call CoRegisterClassObject (**), similar to how the CoInitializeEx call is made by ComObj.pas. InitProc is called from Vcl.Forms.Application.Initialize which is called from Vcl.SvcMgr.TServiceApplication.Initialize.
Now, when Vcl.SvcMgr.TServiceApplication.Installing returns true, that means StartServiceCtrlDispatcher will not to be called. Because the main thread is not going to connect with the service control manager. Instead it will either install or uninstall services and then exit. Then the need for any delayed initialization will become void and in fact a delayed initialization cannot run since no service thread will run (***).
And so this is why the expression is written the way it is, there are no forgotten/missing parenthesis.
(*) D2007 has the comment at which time 2003 R2 is the last server.
(**) From the comment in the project source:
Windows 2003 Server requires StartServiceCtrlDispatcher to be called before CoRegisterClassObject, which can be called indirectly by Application.Initialize.
(***) This is where a delayed initialization is called, guarded by a flag in case there is more than one service in the executable.
I'm trying to connect my Windows XP program (Lazarus) to my Ubuntu postgres server.
When the Lazarus program runs, it seems to compile fine but I get this error:
Project ... raised exception class 'RunError(211)'.
Then it terminates execution (and I don't see any output), and opens up a file customform.inc. In that file, it shows a procedure procedure TCustomForm.DoCreate; where it highlights a line: if Assigned(FOnCreate) then FOnCreate(Self);
I believe this is one of the system's files.
I never get to see any output.
What could this be? Thanks!
MORE INFO:
I've narrowed down the error to this line:
dbQuery_Menu.SQL.Text:='Select * From "tblMenus"';
dbQuery_Menu.Open;
the exception is triggered when the OPEN statement gets executed.
BTW, dbQuery_Menu is defined as a TSQLQuery component.
Clueless! :(
Run error 211 appears when you try to call an abstract method. Check this link from more information on FreePascal/Lazarus runtime errors.
Since you say all is done by code and you have no visual components, the problem probably lies in your code trying to use an ancestor component which has not overriden the Open method. You should be able to solve this by using the correct descendant component.
Another possibility, although I would strongly recommend to avoid this one, is to override the Open method yourself. It should be avoided because if you are using an ancestor component then you probably would have to override more abstract methods.
HTH
After nearly 5 days I found the answer. Many thanks to all thos e ho have contributed with their ideas ESPECIALLY RRUZ, RBA and Guillem Vicens. there are other related posts all connected to getting the FIRST Lazarus program working with PostgreSQL.
Summary.
The biggest mistake I made here was that I used the TSQLConnection component. Don't do this. Instead use the TPQConnection.
Everything is done through code. We're not using any draggable components from the top tab.
Don't rely on the Lazarus docs (wiki) at least for working with PG DBs.. It is outdated. Some of the examples can be pretty misleading.
Make sure that fields have some default values. For example, if a Boolean field has no true or false (t/f) set, this may lead to errors.
And that's it! I hope many postgres+Lazarus newbies will find this useful.
From here - http://www.network-theory.co.uk/docs/postgresql9/vol2/SQLSTATEvsSQLCODE.html - -211 (ECPG_CONVERT_BOOL) This means the host variable is of type bool and the datum in the database is neither 't' nor 'f'. (SQLSTATE 42804)
There are several questions on StackOverflow that seem to have answers that contradict each other on the subject of ADO/OleDB, delphi TADOQuery/TADOCommand and the subject of parameters.
Parameters can be introduced two ways, in the CommandText or SQL property of an ADO component. Named parameters, which work most of the time for me, are introduced with colons:
select a, b, c from bar where bat = :baz
This works, 99% of the time for me, just fine. Every now and then I find that ADO or Delphi's wrappers around it, won't accept ":baz" and requires that I write this instead:
select f, g, h from bar where bat = ?
This results in an unnamed parameter, instead of a named parameter. When an ADO Query or ADO Command contains only one parameter, this isn't a big deal. But that's not when ADO acts up on me. Yesterday it acted one way, and today, a different way with a dual-command in a single TADOCommand object, like this, with two commands in one CommandText string:
delete from bar where id = :id1
delete from bat where id = :id2
I had to change it to this:
delete from bar where id = ?
delete from bat where id = ?
It worked all day yesterday. Today, I had to change it back to the first version, to get it to work. The symptom was that the ADO parameters disappeared and would not come back, and when I try to execute the command I get an error, index out of range, when I try to access Parameters[0]. Nothing gives me any warning that the parameters are going away. It seems that a few connections to the ADO dataset, at designtime, jogs the TADOCommand component, in particular, and it "just breaks on me". It is particularly maddening when you're trying to write a query or a command, and you know it works, but the ADO component has decided not to accept "?" or ":x" right now. You can get around its total inability to function by switching from one to the other. But it frustrates me, and probably actually completely blocks other people. I know some people always dynamically build their SQL in code, and avoid using Parameters, and maybe this is why.
Possible answers to my question that I'm anticipating are:
ADO doesn't support multiple commands, or at least Delphi's wrappers don't. Or maybe TADOCommand just doesn't work reliably here.
Parameters are a buggy area in all of ADO, or all of Delphi's ADO wrappers?
You're doing it wrong.
I'm using Delphi XE2, but I've seen similarly dodgy behaviour in 2007, 2009, 2010, and XE.
I'm using Microsoft OLEDB Provider for SQL Server as my OLEDB Provider.
Named parameters with :? I always used it with #, even on Visual Studio (ADO.NET).
And in T-SQL parameters and variable are prefixed with #.
Do not remember having problems with that... Are you sure you doesn't choose Native Client
(installed with an SQL server client install) instead of OLEDB Provider for SQL Server (which
comes with Windows)?
Unfortunately, I've not used Delphi in awhile, so, and I don't have the means to validate this answer from the Delphi perspective.
This is the first time I've seen named parameters prefixed with a colon (:). Usually, in ADODB, the named parameters are prefixed with an at (#) and, yes, unnamed parameters are given with a question mark (?).
One significant advantage of named parameters is their ability to be reused, i.e.
INSERT INTO TABLE T VALUES (#id, #id, 'Hello World');
At the ADODB level. Once you used parameters, either named, or unnamed, you can use CommandText.Parameters.Refresh as a fast means of creating the parameters.
Yes there are some cases where parameters with ? fail. I have found sometimes I need to use :named parameters. Named parameters have an advantage for working with the DB Parameter values, since having the Name property set makes debugging the ADO query or dataset or table easier as well.
I do not understand why. If you have this problem, first check you are using the correct OLEDB provider, and check what version. Also check for potential parsing errors caused by bad SQL generated by you.
I suspect that an internal behaviour inside the OLEDB provider in code that I do not have source code for is to blame for this quirk. The Delphi ADO class wrappers are translators from Delphi's database component layer architecture to ADO's core query/table/dataset APIs all of which are under the hood wrappers around a set of COM objects that deal with ADO RecordSets.
I have written a wizard in Delphi XE, and it is working fine. However, I have not figured out yet how to access the generated default unit name (or form name or project name) that Delphi's OTA can create.
In my old-style wizard I was able to call ToolServices.GetNewModuleName to discover an available unit and form name that I could use when generating the associated source files. What is the equivalent in today's open tools API?
According to the ToolsAPI unit comments, I should return a blank from the IOTAModuleCreator.GetImplFileName method to have Delphi generate the file name. I am returning an empty string from this method, but still cannot see where I can access the file name that Delphi is generating.
There is a specific method for getting a new form and unit name:
(BorlandIDEServices as IOTAModuleServices).GetNewModuleAndClassName(
'', UnitIdent, FormName, FileName);
I've used in a few examples and it seems to work fine.
The method IOTAModuleCreator.NewImplSource have a "ModuleIdent" parametter, it is the unit name.
In my tests, it works as you expected (ModuleIdent parameter in NewImplSource method receives the new unit name). Check your implementation again, especially make sure that:
IOTACreator.GetUnnamed returns True
IOTACreator.GetExisting returns False
IOTACreator.GetCreatorType returns the appropriate identifier (sUnit, sForm, etc.) - I'm not sure about this but it might be important, too
Here is a working example. I just checked it and the code still seems to work as expected in Delphi XE.
I'm trying to get rid of some hints(*) the Delphi compiler emits. Browsing through the ToolsAPI I see a IOTAToolsFilter that looks like it might help me accomplish this through it's Notifier, but I'm not sure how to invoke this (through what xxxServices I can access the filter).
Can anyone tell me if I´m on the right track here? Thanks!
(*) In particular, H2365 about overridden methods not matching the case of the parent. Not so nice when you have about 5 million lines of active code with a slightly different code convention than Embarcadero's. We've been working without hints for months now, and we kinda miss 'm. :-)
Even if you could query BorlandIDEServices for IOTAToolsFilter, that interface isn't going to help you do what you're asking. That interface was introduced as part of a mechanism for adding additional build tools (compilers, etc.) to the IDE (before the IDE used MSBuild). It allowed you to write a custom "filter" to handle output from a particular build tool, but it would not let you apply a filter to one of the built-in tools (like the delphi compiler).
The reason the Supports(BorlandIDEServices, IOTAToolsFilter, OTAToolsFilter) call fails in Delphi2010 is that once MSBuild support was added to the IDE, the old way of adding build tools to the IDE was disabled, and the BorlandIDEServices interface no longer supported IOTAToolsFilter.
The declaration of IOTAToolsFilter should probably have been marked deprecated in ToolsAPI.pas (or least it should have been mentioned in the source code comment that it is no longer supported).
As far as your desire to filter a particular hint, I'm not aware of a way to do that via the ToolsAPI. It seems like a reasonable thing that can be added to IOTAMessageServices (the ability to enumerate, filter, and possibly change the messages in the IDE's Message View). I would enter a request in QualityCentral for that.
Also, please vote for QC #35774 (http://qc.embarcadero.com/wc/qcmain.aspx?d=35774), as if that were implemented, you would not need to use the ToolsAPI for this sort of thing.
According to http://docwiki.embarcadero.com/RADStudio/en/Obtaining_Tools_API_Services it should be possible to access it directly using BorlandIDEServices, eg:
var
OTAToolsFilter: IOTAToolsFilter;
begin
if Supports(BorlandIDEServices, IOTAToolsFilter, OTAToolsFilter) then
ShowMessage('supports IOTAToolsFilter')
else
ShowMessage('IOTAToolsFilter NOT supported');
end;
However this doesn't return the desired interface in Delphi 2010 (you'll get the not supported message), so there's either an error in the documentation, or an error in BorlandIDEServices not returning the correct interface.