Problem is LIKELY the quite old implementation that SAP is using in their jdbc driver, but unfortunately I think I'm stuck with it.
Using Advantage JDBC Driver 11.1
driver loads ok, and I am querying the database, but I suspect APOC is using a much newer JAVA method than this old JDBC driver supports. Following is my query attempt and the resulting error message:
call apoc.load.jdbc('jdbc:extendedsystems:advantage://commitcrm:6262;catalog=//commitcrm.mysite.com/CommitCRM/Db','SELECT source FROM Tickets WHERE source is not null') YIELD row
Neo.ClientError.Procedure.ProcedureCallFailed: Failed to invoke procedure
apoc.load.jdbc: Caused by: java.lang.AbstractMethodError: Method com/extendedsystems/jdbc/advantage/ADSResultSet.isClosed()Z is abstract
Any suggestions, or am I stuck because of this legacy JDBC driver?
Hmm seems this JDBC driver doesn't implement some APIs.
A little bit hard to fix but I can have a look.
Can you test this one? Dropbox - apoc-220.127.116.11-test-jdbc.jar - Simplify your life
That did the trick!
I can do some further testing... This will allow me to do realtime queries to that platform without waiting for our nightly exports into our SQL database.
Should be in the latest release 18.104.22.168
It looks like some small changes in functionality.
In the TEST version I was using, when I queried DATE fields, the returned values were automatically converted into the EPOCH:
In the new version the value being returned is the original STRING from the advantage DB:
Which is fine, I CAN go add conversion routines into my scripts, but the auto-conversion was actually quite convenient! I'm not sure what was the intended output.
I can confirm this now. I discovered this because I was replacing an older dev box (3.4.7) running your test 22.214.171.124 test version of APOC that you compiled for me to fix ADVANTAGE JDBC (thank-you by the way!).
And I build a new test box on 3.4.9 and I put the new 126.96.36.199 APOC in, and that's where the change occurs.
I'm pretty sure that the Advantage database is storiing the date in the string format, and I suspect the test version of 188.8.131.52 was auto-converting to the EPOCH in ms for the date field. (which is actually quite helpful!), while the new 184.108.40.206 version is probably returning the queried field unconverted -- which I am guessing was actually the desired behavior. Maybe I was enjoying the benefits of an unintended bug!
I can't verify for sure, because I don't have a browser/explorer tool handy to look through the original Advantage database.
Thanks Michael! Please let me know if I can help test or validate anything. For now I'm going to continue using the 220.127.116.11 test version because it affords me to be lazy for a few days, and not go fix my CYPHER to add the conversion process after the JDBC query.
Please try the recently released 18.104.22.168 version.
I think this happened again in a recent update to apoc. I'm again getting unconverted (original STRING formatted) dates returned, and the previous APOC was converting these to EPOC automatically.
I can certainly change my code to convert these back to EPOC using apoc.date.parse, but not sure what should be the expected behavior.
My test machine is running APOC 22.214.171.124 and running on Neo4j 3.5.2
edit -- I was going to test to see if going back to APOC 126.96.36.199 would fix it, but I can't get neo4j 3.5.2 to start with apoc 188.8.131.52 plugin...
Ah - that's new... I think my issue is actually that the test version you sent me (to work-around those "old-as-dirt" api methods that the advantage jdbc driver uses) gave me an added bonus feature (it auto-converted the datetime format into the epoch before returning the value). Which was handy, but it seems I can just as easily do this now with datetime(row.CREATEDATE).epochMillis, so that's a pretty simple change in my code.
Thanks again for the follow-up Michael!