Teiid: deprecated floating-point date/time format is not supported by Npgsql - npgsql

I've written a C# netcoreapp 3.1 webapi app that tries to read a Teiid VDB table via Npgsql.EntityFrameworkCore.PostgreSQL 3.1.0.
Whenever my app reads any data like this:
_context.Campaigns.ToList();
the following error occurs:
NotSupportedException: The deprecated floating-point date/time format is not supported by Npgsql.
Googling it I've found this: Npgsql: Old floating point representation for timestamps not supported . Unfortunately, the Npgsql.EntityFrameworkCore.PostgreSQL project stopped supporting the deprecated floating-point date/time format of PostgreSQL but Teiid seems to be still using it.
I've also tried the old version 2.2.4 of Npgsql.EntityFrameworkCore.PostgreSQL with a .net Core 2 app that didn't have this problem but failed to read and write double values from/to Teiid.
AFAIK, the only working way to access Teiid data from .net Core apps is via System.Data.ODBC.
Is there any configuration or tweak on Teiid to make its PostgreSQL emulation using the new integer date/time format?
Or if not, is there any plan to update the Teiid PostgreSQL emulation?

Or if not, is there any plan to update the Teiid PostgreSQL emulation?
I don't think the full context is quite captured here. The current state of the pg emulation is that it supports the binary format only for bytea, integral, float, double, and date types. The driver should be sending time/timestamp in text format.
If additional binary format type support is needed, that would require an enhancement.
As for what binary format to support, we need to match the expectation for the pg version that we are emulating, which is currently 8.2. If there is a connection / session variable to control the expected format we could look to support that.
The last efforts to support npgsql were two years ago, so it's likely that their driver is now doing things that we didn't expect. So you should log an enhancement about supporting the latest and greatest version, which could coordinate any of the subtasks.

Related

Data base with unicode support for cross-platform mobile application

I am rewriting my app for iOS using react-native in order to support both Android and iOS platforms.
I have tried Realm as a database and have faced with lack of unicode support for react-native.
On iOS I used core data and everything was ok.
Are there any database for react-native with unicode support?
What is usual/useful pattern when introducing a database to a cross-platform mobile application? Should I add it on the highest level, for all platforms, or should I do it separately for each platform?
Update:
Realm team officially told me that there is no unicode support for react-native(https://forums.realm.io/t/issue-with-requests-containing-unicode-characters/994?u=spineight)
From the link you shared, Unicode is in fact supported by Realm, although it does not support case insensitive matching for characters outside of the range UTF-8 0–591:
String sorting and case insensitive queries are only supported for character sets in ‘Latin Basic’, ‘Latin Supplement’, ‘Latin Extended A’, ‘Latin Extended B’ (UTF-8 range 0-591).
As long as you set the encoding to UTF-8 in SQLite, it should let you use SQL LIKE statements, with the help of the UPPER() and LOWER() functions, to do case-insensitive comparing (although the same effect can potentially be achieved in JavaScript and Realm). See this.

Convert nested XML file to some kind of database format and displaying on website

Heyos!
I am in sincere need of help and advice with a project I have to work on.
Let me give you a brief overview:
Context:
MeSH-Browser is a website used for displaying "[...] hierarchically-organized terminology for indexing and cataloging of biomedical information [...]" (see: https://www.nlm.nih.gov/mesh/).
The MeSH-data can be downloaded from here: https://www.nlm.nih.gov/mesh/download_mesh.html
What is the task:
Displaying MeSH-data on a website.
What is given:
MeSH-data as mentioned above (see: https://www.nlm.nih.gov/mesh/download_mesh.html).
What is the catch:
I have no experience in developing a back- and frontend.
What I have come up so far:
I figured out that I need to develop a back- and frontend as well as the communication between those.
Convert given MeSH-data in .xml format to database input format.
Create a server running a database fed with the converted MeSH-data.
Communication between database and website.
A website for displaying the data stored in the database.
After googling I found a GitHub project with "Code and documentation for the release of MeSH in RDF format" (see: https://github.com/HHS/meshrdf/).
Hence I set up a virtual machine running an ubuntu server and installed OpenLink's Virtuoso software (see: https://virtuoso.openlinksw.com/), which can be used for querying the resulting RDF.
What has to be done next is integrating the converted MeSH-data in RDF into the Virtuoso database (have not looked into this yet).
Considering the communication with the frontend, I was thinking about using one of the libraries mentioned on https://www.w3.org/community/rdfjs/wiki/Comparison_of_RDFJS_libraries and query the data with the help of SPARQL.
As frontend I would use ReactJS as I find it appealing to me.
That is all for now, what are your opinions?
Please do note that this is only for educational purposes.

DateTime Covert on data post using WebApi?

I am working on MVC 4 project with AngularJS. I have some date filed in my form. I am facing an strange issue when i post data to server using $http.post(). When i post any date like January 01,2013 is converted to 12/31/2012 on Server which gives an error on Server Post. I am not getting what is going wrong in my code base.
Hope you got my question.
When dealing with dates you have to be careful as to how they are serialised on the front-end and back-end. There is no standard.
Given your description and lack of other context though, I suspect it's a time zone issue.
are you developing locally? i.e. are browser and server running on the same machine?
(if not) what's the timezone the server is using? UTC?
Here's a post detailing some issues with JSON date serialization: "On the nightmare that is JSON Dates. Plus, JSON.NET and ASP.NET Web API"
If you're not sure what's going on with serialisation you can use something like curl (*nix or maybe cygwin tool) or "Fiddler" to see the raw responses. Other things to do are to explicitly use date's toString() method to serialise the date as a string (and change on the server side too seeing you're using .Net) to explicitly control the deserialisation.

How can I implement Schematron validation (ISO) to my xml file in PHP for XSLT2?

I need to implement schematron validation to my xml file using PHP and XSLT2 (not XSLT1). I need to do so using latest version of schematron ie. ISO. Where can I get code in PHP for the same. I researched and find out that XSLT2 processor is not supported in PHP till now. There are few code available on net but they are old version and do not support XSLT2. Please help

How to access databases from within Delphi XE Professional IDE?

I cannot access ANY database by ANY means from within Delphi XE Professional. What I mean by accessing the data base is:
having the live database appear via
components in the Object Inspector,
when the connected property is set
to true
using the Data Explorer to create
and explore database connections
EDIT:
SORTED !!
The core problem is that communication into the database, including specifically the communication generated by the IDE and any code built using the drivers was problematic.
Confounding and masking sub-issues were:
Missing or misplaced DLLs.
The Data Explorer does not fully support dbExpress drivers.
There is a bug within the 2009 IDE code, found by Chee-Yang Chau when writing the dbxFirebird driver, which limits static linking of drivers into Delphi. It is not known if this bug extends to 2010 or XE.
When using the Object Inspector, it is easy to cause the IDE to revert changed connection parameters to their default values.
Some drivers had incorrect default values (eg assuming the client dll was always gdb32.dll irrespective of whether the database was Interbase or Firebird).
Installation of two versions of Interbase led to some clashes in database communication - server names generated by the tools were odd; and the view of the databases depended on which installation of the Interbase tools were used.
The documentation available is of varying dates; refers to different versions; and as a result often appears contradictory.
END EDIT:
Approaches tried:
Multiple databases
Multiple different drivers/components
Accessing the database through other external tools, such as IBSQL and Flame Robin.
Raising questions (here and here) on SO.
Raising questions on the support forums for Firebird, Embarcardo, and Flame Robin.
Environment:
OS: Windows 7 Ultimate 64bit:
Delphi Embarcadero® RAD Studio XE Professional Version 15.0.3953.35171
Database: W1-V2.5.0.26074 Firebird 2.5 (64 bit)
Connection technology: dbExpress
Delphi Professional does not support Firebird with the native dbExpress drivers that come with Delphi. You need the Enterprise or Architect version of Delphi in order for the native firebird dbExpress driver to work.
I have Delphi 2010 Professional. I didn't want to spend the extra money on the E or A version and I failed to read the feature matrix to see that the Firebird dbExpress driver is not available with the Pro version.
I have found a few really nice videos that show how to connect to Firebird using Delphi. However, when I tried to follow along with my Professonal version nothing worked.
Shame on me and more shame on Embarcadero for touting that Delphi supports Firebird in big bold print but not mentioning that you need the Enterprise or Architect version except in the tiny fine print.
I can now write code to access Firebird within the IDE. I have (limited, but sufficient) access to the drivers within the IDE. Specifically, the drivers appear in the Data Explorer, which can be used to generate default values for the SQLConnection (dbExpress component). These can be accessed and used within the Object Inspector. The workaround to the IDE bug quoted below is necessary to ensure the communication parameters are correct. When writing database code, it is necessary to compile in the source for the dbExpress driver.
The following code is the minimum, with minimum parameter set, necessary to establish and test a database connection:
unit Unit2;
interface
uses Classes, SqlExpr, Dialogs, dbxDevartInterbase;
var SQLConnection1 : TSQLConnection;
implementation
{$R *.dfm}
begin
SQLConnection1 := TSQLConnection.Create(nil);
with SQLConnection1 do
begin
ConnectionName := 'TestConnection';
DriverName := 'DevartInterBase';
LibraryName := 'dbexpida40.dll';
VendorLib := 'fbclient.dll';
GetDriverFunc := 'getSQLDriverInterBase';
Params.Clear;
Params.Add('User_Name=SYSDBA');
Params.Add('Password=masterkey');
Params.Add('Database=localhost:C:\Program Files\Firebird\Firebird_2_5\examples\empbuild\employee.fdb');
Open;
If Connected then ShowMessage('Connection is active');
Free;
end;
end.
The workaround, courtesy of Bob Swart on one of the Codegear forums is:
The trick is to select a
ConnectionName value, which will then
assign a value to the Driver property
and all other properties like
LibraryName, VendorLib and
GetDriverFunc.
Then, make changes - if needed - to
the subproperties of the Driver
property, and finally clear the name
of the Driver property.
This will leave all your changes in
the Params list (which you can also
manually edit if you wish).
Note: leave the ConnectionName set -
if you clear that one, the parameters
will be cleared again.
Now you can compile your application
and deploy it without the need for
dbxdrivers.exe or dbxconnections.ini
(but you need to deploy the DLLs
specified in the LibraryName and
VendorLib, of course).
Also make sure to set LoginPrompt to
False and leave LoadParamsOnConnect
set to False, too.
BOUNTY AWARD
I have awarded the bounty to this answer as it was the one that pointed me away from investigation of the IDE, its installation and configuration, to investigation of the connection into the database.
END
DK about Firebird 64 bit - -no experience. But I've always had a lot of trouble with dbExpress. Never any problem with the included IB components suite. But there is a lot of confusion with IB versions...
But IMO you're best served using the ADO ('DBGo') components as opposed to any proprietary IB or Delphi specific drivers. What you need is an ADO provider for IB, available #:
http://www.ibprovider.com/eng/ - and as others have said, avoid using localhost, use 127.0.0.1, or better still, determine the true IP address of your workstation (ping machine-name...) And are you sure you don't have some kind of firewall or intrustion protection that may be involved?
You also need to make sure that your IB connection is configured properly - local or TCP, and no, don't use quotation marks for your names, pwrds, etc. The error message you got seems to indicate that you're trying to connect via TCP and it's not properly configured. What happened between the time it worked and the time it didn't work? Shut down Delphi? Reboot the machine? Explain please....
No 'special permissions' are needed - you simply need to ensure that your database server and client are properly installed and configured. In terms of functionality you can do everything with the pro version - just that the drivers etc aren't included in the package.
Again, IMO go for ADO and you'll never look back.
HTH,
MNG
Have you tried Paradox via the Borland Database Engine (BDE) and related components: TTable TQuery TStoredProc TDatabase and TSession?
If memory serves me correctly, at least as far back as Delphi 3, the distinguishing factor between "professional" and the "higher-level" editions has been the type of database development "out the box".
In Delphi 1, the BDE was the only way to do out-the-box database development.
Delphi 2 permitted a custom database layer by abstracting parts of the database component hierarchy.
Delphi 3 Professional provided BDE and drivers for file-based databases and Interbase.
One level up (Enterprise?*) they provided BDE drivers for typical client-server database access: SQL Server, Sybase, Interbase, Oracle,... (and native drivers for Interbase)
Another level up (Architect?*) introduced multi-tier development with Midas. Unfortunately, Borland took a step back with Midas, because the multi-tier components were again hard-wired to the BDE. (This was resolved in Delphi 4.)
?* Please note, I may be mistaken about the exact naming of these editions. Around about that time I formed the opinion that Borland was merely coming up with "grander" names in order to charge more for features that didn't really offer as much benefit as the 'big-cheque-writing-CIOs' came to believe - leaving developers to deal with the fallout. (Yes, I have battle-scars from Midas I.)
Rant aside, the theory was....
If one embarked on entry-level database development, you would purchase Delphi ?? Professional. Develop your system against a file-based database or Interbase via the BDE.
If you later needed to scale-up: you would upgrade Delphi, purchase your chosen SQL RDBMS, switch your connectivity via the TDatabase component, and apply the few necessary tweaks.
NOTE: In Delphi 3, you could switch to Native Interbase (personally not recommended) or use third-party components for non-Midas development. From Delphi 4 up, ADO and DevExpress started receiving more attention and nowdays, the BDE seems to be pretty much forgotten.
Of course theory & practice seldom frequent the same pubs. However, with a few cautionary pointers, you should be able to develop a significant file based solution that can be upgraded relatively painlessly.
Keep your business logic out of the database. This is quite possibly the biggest and most frequently encountered error. Huge chunks of systems are often written in triggers and stored procedures, making it more difficult to maintain or migrate a system.
Avoid platform-specific database techniques. This should go without saying, but if you don't explicitly look out for them, you will encounter problems.
Particularly relevant to file based database systems, many support special locking mechanisms - avoid them! They don't scale well to large multi-user systems in any case.
Generating of artificial keys often varies by platform: Generators, IDENTITY columns, how you get the new value.
Plan your system for large volumes of data. Identify the high-transaction tables, and avoid using uncontrolled retrieval of all records. I'd also avoid the TTable in this situation - BDE does a lot of interesting background things with TTable, and behaviour can vary according to driver and platform.
Disclaimer: All this was a long time ago, so some of the details may be a bit sketchy.
Disclaimer2: I don't have any experience with Delphi XE specifically. I currently use D5 professionally, and D2009 in my personal capacity.

Resources