I just installed the latest version of Embarcadero Delphi XE3. I made a simple form connecting to InterBase Database. I have IBDatabase, IBTable, IBTransaction, Grid and some other components. Everything works fine and it shows data in the grid. But I want to be able to edit this data. So at the IBTable component I set the ReadOnly property to false and every time I do this the program stops working and I get this:
Dynamic SQL Error
SQL error code = - 206
Column unknown
IBTable1
Any idea how to solve this?
It is not recommended to use IBTable component. Usage of IBDataset or IBQuery is advised. Read this
Related
I'm using Firedac to connect to a Firebird 2.1 database in Delphi 10.1 Berlin. A TFDConnection has a TFDtransaction assigned. Both with default values. Then there's a code like that, more or less.
TFDtransaction.StartTransaction;
try
.. // Select, update & insert statements in TFDQuery components created dinamically here with default values
TFDtransaction.Commit;
except
TFDtransaction.Rollback;
end;
The problem is, sometimes (not always), when checking the values changed by this transaction (in FlameRobin, for example) I can't see the new values until I close the application (that is closing the connection too). Why is that so? How I can solve this? Is there a problem in the update options in the TFDConnection component?
I have got this problem with FireDAC -> FDQuery component when it tries to select data from a database with '.' (dot) in its name.
The database name is TEST_2.0 and the error on Opening the dataset says:
Could not find server 'TEST_2' in sys.servers [...]
I have tried {TEST_2.0} (curly brackets) and [TEST_2.0] (square brackets). Also setting QuotedIdentifiers (Format Opetions) property to True does not seem to fix the problem. In SQL query I can add 'SET QUOTED_IDENTIFIER ON;' but this breaks inserts to the dataset.
The FDConnection component can connect to that server and that database using MSSQL driver without problems. It seems it is the dataset that dosn't handle it. UniDAC seems to handle everything without any problems.
I am using RadStudio 10.2.
Has anyone found any solution to this? Thanks in advance for any replies
I got a response from Emarcadero and it works for me:
"The problem is not in FireDAC, but in SQL Server ODBC driver
SQLPrimaryKeys function. It fails to work with a catalog name
containing a dot. FireDAC uses this function to get primary key fields
for a result set, when fiMeta is included into FetchOptions.Items. So,
as a workaround / solution, please exclude fiMeta from
FetchOptions.Items."
What is wrong?
I was able to reproduce what you've described here. I've ended up on metainformation command, specifically the SQLPrimaryKeys ODBC function call. I have used SQL Server Native Client 11.0 driver connected to Microsoft SQL Server Express 12.0.2000.8, local database server instance.
When I tried to execute the following SQL command (with TEST_2.0 database created) through a TFDQuery component instance with default settings (linked connection object was left with empty database connection parameter) in Delphi Tokyo application:
SELECT * FROM [TEST_2.0].INFORMATION_SCHEMA.TABLES
I got this exception raised when the SQLPrimaryKeys function was called with the CatalogName parameter set to TEST_2.0 (from within the metainformation statement method Execute):
[FireDAC][Phys][ODBC][Microsoft][SQL Server Native Client 11.0][SQL
Server]Could not find server 'TEST_2' in sys.servers. Verify that the
correct server name was specified. If necessary, execute the stored
procedure sp_addlinkedserver to add the server to sys.servers.'.
My next attempt was naturally modifying that CatalogName parameter value to [TEST_2.0] whilst debugging, but even that failed with similar reason (just failed for the name [TEST_2), so for me it seems that the SQLPrimaryKeys ODBC function implementation with the driver I've used cannot properly handle dotted CatalogName parameter values (it seems to ignore everything after dot).
What can I do?
The only solution seems to be just fixing ODBC drivers. Workaround I would suggest is not using dots in database names (as discussed e.g. in this thread). Another might be preventing FireDAC from getting dataset object metadata (by excluding fiMeta option from the Items option set). That will bring you the responsability of supplying dataset object metadata by yourself (at this time only primary key definition).
I have a Delphi 7 app using Paradox database via BDE, that I have converted to Delphi XE3 and Firebird. There is a string field in the Paradox database containing an encrypted string that is supposedly used for licensing of the software. The problem is that while a routine that read this string in the old program (D7/Paradox) worked fine, in the new program (XE3/Firebird) the routine is throwing an error. The cause I have found through debugging is that the string after being read from the database is different. How can I fix this?
The string in the old Paradox database:
Ng-DrLrDOtfâtD89D1'D'îu
The string in the new Firebird database:
Ng-DrLrDOtfâtD89D1'D'îu
As you can see above the string is the same in both databases.
In the new Delphi XE3 program, using UniDAC data access components when I try to get the value of the field using FieldByName('fieldname').AsString , this is what is returned:
Ng-DrLrDOtfâtD89D1'D'îu
You can see that a couple of characters are different. This is causing an error in the routine that is checking this string in program. Did you experience this before? What are the possible causes of this problem and what steps can I take to resolve this.
Note 1: I converted the Paradox database to Firebird with a converter that I wrote in Delphi (For the actual code for this converter, see: http://goo.gl/6xu2ST)
Note 2: I have the database created with DEFAULT CHARACTER SET UTF8 and the UniDAC connection component (TUniConnection) has got SpecificOptions CharSet set to 'UTF8'.
I solved the problem by:
In the data-module or code, set the TUniConnection component property SpecificOptions UseUnicode to True.
Close the project and the Delphi IDE. Open WinGrep and do a Find-Replace in all the project PAS and DFM files for the string: TStringField, changing it to TWideStringField.
Re-compile.
And voila, its working perfect! Errors caused at runtime due to incomplete translation/interpretation of Unicode characters from database has gone away.
Thank you everyone who responded earlier.
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)
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.