Firstly, congratulations on the driver, it seems to be a solid piece of software.
I am currently working on moving a 3rd party Java application and MS Access database from a Windows to a Linux environment.
The UCanAccess driver has allowed me to swap out the JDBC-ODBC Bridge and MS ODBC drivers and run the application on Linux.
However, for reasons beyond my control, the application's processing and output is dependant on the order in which the rows are returned from the query (over and above the order by clause present on the query) and this is causing a different output to be produced when run on Linux with the UCanAccess driver.
I have performed some comparison tests between the results of running the query using the JDBC-ODBC Bridge and MS ODBC drivers and then using the UCanAccess drivers and I can see that all the data retuned is complete but the rows are in a different order.
I have also tried with a couple of other (not free) drivers and they return the data in the same order as the JDBC-ODBC Bridge and MS ODBC drivers.
So, I know it's a bit of a long shot, but are there any settings within UCanAccess that would change the behaviour to mirror that of the JDBC-ODBC Bridge and MS ODBC drivers?
Many thanks
Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I've understood, you would need that the rows order were the same of the odbc, even if you the row order isn't predetermined by an existent ORDER BY clause (because you can't change the queries SQL code).
If so, a solution to this issue isn't currently available, but I would like analyze this behavior.
It would be great if you could upload a database with some tables, queries and few data(created starting from your real db) to help me to reproduce the issue.
Thanks in advance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Marco,
Many thanks for your reply and the offer to investigate.
You have understood my problem perfectly and hopefully the attached files will further illustrate the situation.
I have attached a stripped down version of the database. It contains a few tables, queries and data which will reproduce the effect I am seeing.
You will want to look at the results of running the eGate_Ref_Data_New_Ser_View query, and in particular the rows with Application_A_Row_ID = 1014738 and 1013558.
I have also attached two files which capture the results of iterating over the result set returned by the query, one using the odbc driver and the other using the UCanAccess driver. You will see that the order of the two rows mentioned above have been reversed.
Thanks again, and please let me know if you require any further information.
Steve
Thank you so much, now I can reproduce the issue.
This task could take some time but I'll let you know my findings as soon as they are available.
Cheers Marco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Marco,
Please do not spend any more time on this issue.
After further testing, it would appear that the other drivers I tried are also exhibiting the same behaviour, therefore I doubt if this effect is resolvable.
Many thanks for your time so far!
Regards
Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Firstly, congratulations on the driver, it seems to be a solid piece of software.
I am currently working on moving a 3rd party Java application and MS Access database from a Windows to a Linux environment.
The UCanAccess driver has allowed me to swap out the JDBC-ODBC Bridge and MS ODBC drivers and run the application on Linux.
However, for reasons beyond my control, the application's processing and output is dependant on the order in which the rows are returned from the query (over and above the order by clause present on the query) and this is causing a different output to be produced when run on Linux with the UCanAccess driver.
I have performed some comparison tests between the results of running the query using the JDBC-ODBC Bridge and MS ODBC drivers and then using the UCanAccess drivers and I can see that all the data retuned is complete but the rows are in a different order.
I have also tried with a couple of other (not free) drivers and they return the data in the same order as the JDBC-ODBC Bridge and MS ODBC drivers.
So, I know it's a bit of a long shot, but are there any settings within UCanAccess that would change the behaviour to mirror that of the JDBC-ODBC Bridge and MS ODBC drivers?
Many thanks
Steve
If I've understood, you would need that the rows order were the same of the odbc, even if you the row order isn't predetermined by an existent ORDER BY clause (because you can't change the queries SQL code).
If so, a solution to this issue isn't currently available, but I would like analyze this behavior.
It would be great if you could upload a database with some tables, queries and few data(created starting from your real db) to help me to reproduce the issue.
Thanks in advance.
Hi Marco,
Many thanks for your reply and the offer to investigate.
You have understood my problem perfectly and hopefully the attached files will further illustrate the situation.
I have attached a stripped down version of the database. It contains a few tables, queries and data which will reproduce the effect I am seeing.
You will want to look at the results of running the eGate_Ref_Data_New_Ser_View query, and in particular the rows with Application_A_Row_ID = 1014738 and 1013558.
I have also attached two files which capture the results of iterating over the result set returned by the query, one using the odbc driver and the other using the UCanAccess driver. You will see that the order of the two rows mentioned above have been reversed.
Thanks again, and please let me know if you require any further information.
Steve
odbc file
UCanAccess file
Thank you so much, now I can reproduce the issue.
This task could take some time but I'll let you know my findings as soon as they are available.
Cheers Marco
Many thanks Marco, I'll look forward to your update.
Hi Marco,
Please do not spend any more time on this issue.
After further testing, it would appear that the other drivers I tried are also exhibiting the same behaviour, therefore I doubt if this effect is resolvable.
Many thanks for your time so far!
Regards
Steve
Okey, thanks!