1

I have read in the documentation (http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Defining_Connection_(FireDAC)) that one must set the connection parameter "UnknownFormat" to "BYTEA", to avoid this error. However, I have set that parameter and still get that error.

Details: A simple VCL forms application with an FDConnection and an FDQuery. Tested the FDConnection and set the UnknownFormat parameter to ufBYTEA. Put an SQL select statement in the FDQuery which selects a geometry field from a table. On Execute I get the error.

Victoria
  • 7,822
  • 2
  • 21
  • 44
Reinier
  • 459
  • 2
  • 4
  • 13

1 Answers1

1

Reproduced in Delphi Tokyo 10.2.3 with PostgreSQL 10.1, PostGIS 2.4.3. Issue report RSP-20251.

But I believe it's irrelevant as I guess you've simply returned raw geometry data (as they are stored by PostGIS) without proper geometry output. It's because when you returned your data e.g. in the WKB format by using the ST_AsBinary function, the column would be described by the statement.

So review your SQL command and check if you're not returning raw geometry. If so, return proper geometry output instead.

Victoria
  • 7,822
  • 2
  • 21
  • 44
  • This at least solves my problem, so thanks a lot! (but I still don't understand why that error message appears) – Reinier Mar 30 '18 at 07:20
  • You're welcome! It resolves your problem, because you should not process raw internal PostGIS data format. And as I said, I cannot reproduce what you describe with the mentioned tools. I've checked the Tokyo source and it's correctly implemented (exception is raised only if `UnknownFormat` connection parameter defaults to `Error`). And that PostGIS returns undescribed column when returning raw geometry is very well done. – Victoria Mar 30 '18 at 08:00
  • Are you referring to function TPgTypesManager.Describe (in unit FireDAC.Phys.PGWrapper)? When I step through it in the debugger (Tokyo 10.2.3), the test on FConnection.UnknownFormat is never performed because sType='b' (for the type with the name 'geometry'), so the preceding else condition is not fulfilled. – Reinier Mar 30 '18 at 08:54
  • Yes, that one. There is `(sType <> 'e') and (sType <> 'r')`, so the condition is fulfilled. Actually, you wouldn't get that exception raised if it wouldn't. But if you are in, check the `FConnection.UnknownFormat` value. It should be non zero (should be value of 17, actually). Well, at least as long as nothing changed (I'm running original Tokyo; haven't updated yet). – Victoria Mar 30 '18 at 09:05
  • So I guess this is the problem: In my code it reads (sType <> 'e') and (sType <> 'r') and (sType <> 'b'). The code I have under 18.0 (Berlin IIRC) does not have the (sType <> 'b') part.. – Reinier Mar 30 '18 at 09:27
  • I'll update my Delphi, and optionally file a report about the `UnknownFormat` misbehavior (if necessary). But it doesn't change anything about my suggestion to not process internal raw geometry data type. You should use conversion to WKB if you want binary data, or WKT if you want text representation of your geometry data. – Victoria Mar 30 '18 at 17:35
  • Now looking at the 10.2.3 code, there is added attempt to determine basic type kind returned by the statement with no fallback to the `UnknownFormat`, so I'm about to file a bug report about this. – Victoria Mar 30 '18 at 23:17