Walter Prins

Member since: Monday, 15 February 2016
Last login: 1 month ago
Profile viewed: 586 views

No Rank
Points: 0

DavidI is friends with Walter Prins

Walter Prins created a new topic ' Delphi 10 Seattle Datasnap via HTTP: Correctly usi' in the forum. 3 years ago

Repost of question posted here, here and here.

I am working on a Datasnap server with multiple ServerMethods classes. These are then exposed via HTTP/S etc via TDSHTTPService as normal. I'm now trying to implement distinct authentication appropriate to each service area/context/realm. This appears as though it should be possible using the "Context" parameter in the Datasnap TDSAuthenticationManager OnUserAuthenticate event to vary the authentication check employed. However I'm running into problems:

What I've tried:

1) Changed the client side TSQLConnection.Driver.DatasnapContext from "datasnap" to "datasnaptest", and changed the corresponding server side TDSHTTPService.DSContext from "datasnap/" to "datasnaptest/". Attempting to connect succeeds but in the OnUserAuthenticate event the "Context" parameter is empty. Consequently I tried the following:

2) Changed the client side TSQLConnection.Driver.DatasnapContext from "datasnap" to e.g. "datasnap/test", and changed the corresponding server side TDSHTTPService.DSContext from "datasnap/" to "datasnap/test/". Attempting to then connect fails with 'HTTP/1.1 404 Expected datasnap context in request /datasnap/test/tunnel'.

3) Reverted the TSQLConnection.Driver.DatasnapContext and then changed the client side TSQLConnection.Driver.URLPath from "" to "test", and correspondingly changed the server side TDSHTTPService.DSContext to 'test/datasnap/'. Attepmting to then connect similarly fails with 'HTTP/1.1 404 Expected datasnap context in request /test/datasnap/tunnel.'

In short: How does one correctly manage different authentications (related to different/multiple server classes, and therefore exposed under different URLs/Realms from HTTP) in a Delphi 10 Seattle Datasnap server?

Futher background: We have several app servers and web services/interfaces (Webbroker/SOAP and old school datasnap) which we want to unify/modernize under the new style datasnap framework.

Read More...

Walter Prins replied to the topic 'Cannot login to Quality Portal' in the forum. 3 years ago

Are you using your email or your EDN username to log in? I had similar problems originally with the quality portal as I was absent mindedly using my email address to log in. For the Quality portal (for whatever reason) you *have* to use your EDN *username* and password. Email does not work.

Read More...

Walter Prins replied to the topic 'FireDAC w. iSeries v6r1 - read only/won't update' in the forum. 3 years ago

To add some detail to my original post (posted on G+ this morning):

"The basic problem is that basic dataset based update code simply does not work. That is, setting up a TFDConnection, TFDQuery and then attempting to update a table just simply does not work. The dataset is eiter read-only, or if I "force things" (for example by setting "UpdateNonBaseTables" or by unsetting "UpdateOptions.CheckReadOnly") then errors are generated.

Specifically, setting "UpdateNonBaseTables" to True allows the dataset to go into edit mode but then generates the following error:

EODBCNativeException with message '[FireDAC][Phys][ODBC][IBM][System i Access ODBC Driver][DB2 for i5/OS]SQL0104 - Token . was not valid. Valid tokens: , FROM INTO.'"

Using the FireDAC Monitor to trace the calls, I can see the origin of this error, the SQL generated is as follows:

TEST: TFDDAptTableAdapter($03776BF0).Lock: TFDPhysODBCCommand($036F86B0).Unprepare [Command="SELECT
FROM TESTWP.TEST A
WHERE A.ID = :OLD_ID AND A.SOMETEXT = :OLD_SOMETEXT
FOR UPDATE"]

As you can see no field list is being generated for reasons I don't understand.

If instead I clear UpdateOptions.CheckReadOnly, then the following error is generated instead:

[FireDAC][Phys]-329. Cannot generate update query. WHERE condition is empty.

Again, this seems to be somehow related to the fields being not considered for inclusion for updating/locating records for reasons unknown. "

Read More...

Walter Prins created a new topic ' FireDAC w. iSeries v6r1 - read only/won't update' in the forum. 3 years ago

[color=#000000; font-family: Arial, Helvetica, sans-serif; font-size: 12px; line-height: normal][Also posted on old forums][/color]
[color=#000000; font-family: Arial, Helvetica, sans-serif; font-size: 12px; line-height: normal]Hello, [/color]

[color=#000000; font-family: Arial, Helvetica, sans-serif; font-size: 12px; line-height: normal]I am running into a perplexing problem with FireDAC via ODBC against an iSeries running v6r1 OS and using the latest ODBC drivers from the v7r1 PC software install. (Unfortunately I don't have exact matching drivers/software available, but note that all other software works entirely without incident, including accessing the iSeries using several other data access layers, including [BDE->ODBC] and DBX, all of which works fine so fundamentally this doesn't seem to be a version issue.) I'm using Windows 10 and Delphi 10 Seattle.[/color]

[color=#000000; font-family: Arial, Helvetica, sans-serif; font-size: 12px; line-height: normal]The symptoms are basically that no matter what options I use in connecting to the AS/400, the resultant TFDQuery (with simple select against single table) is read-only and fails to actually update the AS/400 when using normal Edit()/Post() methods or data aware controls. Has anyone else run into this problem? What am I missing?[/color]

[color=#000000; font-family: Arial, Helvetica, sans-serif; font-size: 12px; line-height: normal]Information from FireDAC connection editor is as follows:[/color]

================================Connection definition parameters================================ODBCDriver=iSeries Access ODBC DriverUser_Name=sqltestPassword=*****MonitorBy=RemoteODBCAdvanced=SYSTEM=S44H5004;DefaultLibraries=,TFERDTA,MAFHAM,TESTDTA6,TESTDTA,TESTWP;Naming=1DriverID=ODBC================================FireDAC info================================Tool = RAD Studio 10 SeattleFireDAC = 13.0.1 (Build 82709)Platform = Windows 32 bitDefines = FireDAC_NOLOCALE_META;FireDAC_MONITOR================================Client info================================Loading driver ODBC ...Loading odbc32.dll driver managerCreating ODBC environment handleDriver Manager version = 03.81.10240.0000================================Session info================================Current catalog =Current schema =Driver name = CWBODBC.DLLDriver version = 06.01.0010Driver conformance = 2DBMS name = DB2/400 SQLDBMS version = 06.01.0014
The CWODBC.DLL (iSeries ODBC driver file) reports as follows: http://postimg.org/image/eo9f2k8xl/
Some other remarks: The FireDAC wizard puts the AS/400 library list in the "Database" property field in FireDAC. This is problematic as this property has a length limit of [IIRC] 32 characters while library lists can be a lot longer. You can however specify an arbitrary length library list by putting it in the ODBCAdvanced property in the iSeries ODBC driver parameter "DefaultLibraries". Above I therefore used a manual ODBCAdvanced string and used so called System Naming convention (Naming=1) to ensure the specified library list was actually used for Table resolution. (So called "SQL naming" does not use the fully library list, and will only resolve unqualified table names in the default library.) I also tried a wizard generated set of parameters (which by default uses SQL naming etc), this made no difference to the above problem.

Read More...