In Release 3.0.0 the Feature were added, that the user gets the case sensitive column name of there sql query. I like the feature, but sometimes I don't get the right reponse in with my database.
So I start digging, what is the problem with my database.
The problem is, that I use views in my MS Access database to much and not always name every column in the views.
To demontrate the problem, I created a testdatabase testDb_star.mdb ( https://github.com/derplakatankleber/ucanaccessTest ).
If you select the view, you get the columnnames "ID", "NAME_TEST". (select * from view1;)
If you select the table, you get the columnnames "ID", "name_test". (select * from table1;)
In the last line is the view 'view1' with the definition:
SELECT table1.* FROM table1;
With the commandline tool you can see the metadata: (query: select * from UCA_METADATA.COLUMNS;)
| 0 | ID | ID | COUNTER | null | NO | 0 |
| 1 | name_test | NAME_TEST | TEXT | null | NO | 0 |
| 2 | * | * | null | null | NO | 1 |
So I search around in the LoadJet.java and could not find a special implementation for star-operator, so that my prefered result with case sensitiv columns would be possible. So I tried to change the code...
prefered result:
| 0 | ID | ID | COUNTER | null | NO | 0 |
| 1 | name_test | NAME_TEST | TEXT | null | NO | 0 |
| 2 | ID | ID | null | null | NO | 1 |
| 3 | name_test | NAME_TEST | null | null | NO | 1 |
You're welcome and thank you for your patch and the outstanding reverse engineering work.
Following a first review, I think the patch should work in general. Once I've done some more test, I'll communicate in this thread my findings. It would be great to add this in the 3.0.4.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes that's correct. Another issue may happen when no table nae is specified: SELECT * FROM ...
in this case I might try to execute the query by adding a 1=0 condition and then reading the resultset metadata... not still sure if using select * from (query) WHERE 1=0
doesn't impact the connection time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In Release 3.0.0 the Feature were added, that the user gets the case sensitive column name of there sql query. I like the feature, but sometimes I don't get the right reponse in with my database.
So I start digging, what is the problem with my database.
The problem is, that I use views in my MS Access database to much and not always name every column in the views.
To demontrate the problem, I created a testdatabase testDb_star.mdb ( https://github.com/derplakatankleber/ucanaccessTest ).
If you select the view, you get the columnnames "ID", "NAME_TEST". (select * from view1;)
If you select the table, you get the columnnames "ID", "name_test". (select * from table1;)
In the last line is the view 'view1' with the definition:
With the commandline tool you can see the metadata: (query: select * from UCA_METADATA.COLUMNS;)
So I search around in the LoadJet.java and could not find a special implementation for star-operator, so that my prefered result with case sensitiv columns would be possible. So I tried to change the code...
prefered result:
Change of code in LoadJet.java and Metadata.java are in the github project ( https://github.com/derplakatankleber/ucanaccessTest ).
I'm not sure if my implementation considered all your implementation requirements,
but I would like to see this feature in future releases.
The patch-files only show the diff between Release UCanAccess-3.0.3.1-src and my implemention.
Thanks for your hard work and I hope for a positive response.
You're welcome and thank you for your patch and the outstanding reverse engineering work.
Following a first review, I think the patch should work in general. Once I've done some more test, I'll communicate in this thread my findings. It would be great to add this in the 3.0.4.
Bugfix: small fix for multicolumn selects. the "return;" statement prevented the identification of additional columns.
Thanks to niks!
For more Info:
https://github.com/derplakatankleber/ucanaccessTest/commit/0c68ef73606eac71bdd71f0ccb4d95b2e8822c03
Yes that's correct. Another issue may happen when no table nae is specified:
SELECT * FROM ...in this case I might try to execute the query by adding a 1=0 condition and then reading the resultset metadata... not still sure if using
select * from (query) WHERE 1=0doesn't impact the connection time.