Add schema and indexes reflection to ADO Access adapter #545

Merged
merged 1 commit into from Sep 5, 2012

Projects

None yet

2 participants

@ericgj
Contributor
ericgj commented Sep 4, 2012

Not expecting this to be merged without some tests, but wanted to see what you thought before pursuing it any further. Some of it is based on the MSSQL adapter code although the underlying mechanism is completely different. It's working for me (MS Jet 4.0 / Access 2003).

@jeremyevans
Owner

This looks interesting. It works for me in brief testing on both Access 2007 (ACE 12) and Access 2003 (Jet 4) databases. It's a lot of new code, so it'll take me a little while to review it all, but this can probably go in. I'll try to find time to review it tomorrow. Thanks for submitting the patch!

Personally, I don't care much about the tests for Access, since it doesn't run with Sequel's integration test suite (tons of "could not lock table" errors, even in single threaded code). If you really want to get good Access support in Sequel, you should look into getting the integration tests working. To run the integration tests on access, add INTEGRATION_DB = Sequel.ado(:conn_string=>'Provider=Microsoft.Jet.OLEDB.4.0;Data Source=drive:\\path\\filename.mdb') to spec/spec_config.rb and then run rake spec_integration.

If that seems like a lot of work (certainly seems that way to me), you just want to add an adapter spec for Access, just testing some basic functionality. Just add a spec/adapters/access_spec.rb file and add the specs there. Even basic testing for Access would be better than the current situation.

@ericgj
Contributor
ericgj commented Sep 5, 2012

Thanks. Re. 'could not lock table' errors, I ran into this before in drop_table. I think it can be "solved" (so to speak) by forcing a reconnect (i.e. disconnect) before any drop_table - possibly before any execute_ddl. I will try that and run the integration tests.

Also I think I can add foreign_key_list by querying Access' built-in table MSysRelationships. I just don't have a burning need for this personally so I didn't do it yet.

@jeremyevans
Owner

Forcing a disconnect will break usage in transactions, but I'm guessing Jet/ACE doesn't support transactional schema modification anyway, so that's a possibility I'm willing to consider, if not globally at least for the specs. We already do something similar for the ibmdb adapter in the specs

Adding foreign_key_list would be good, but by no means a necessity, since the information is pretty much only used by the schema dumper. Is it possible to implement tables and/or views. There is code currently for tables, but it raises a security-related error. Getting tables to work is probably the most important, since it's the first thing used when attempting to introspect the database schema.

@ericgj
Contributor
ericgj commented Sep 5, 2012

I did get tables to work as-is for mdb files, I think the trick is you have to have a user ID and password in your connection string, and the "workgroup file" aka "system database" which is how Access < 2007 does table-level security. So the connection string would be something like Provider=Microsoft.Jet.OLEDB.4.0;Data Source=drive:\\path\\filename.mdb;Jet OLEDB:System Database=drive:\\path\\system.mdw;User ID=Admin;Password=Password

I'm not sure with Access 2007+ which did away with workgroup files, I could investigate.

EDIT: According to this, there's a connection-string setting for ACE 12 files Persist Security Info=False;, which does the trick.

Alternatively, there's a way of getting the tables via OpenSchema as I did for the table structures and indexes, not sure which is more reliable.

@jeremyevans
Owner

I tried the Persist Security Info=False; setting, but it doesn't seem to work with the current code. I don't think you can use an SQL query, you probably need to do the other magic mentioned in the article. If there is a way to get the tables via OpenSchema, that would be great and hopefully work better.

I reviewed the patch and it looks good. The only major change I plan to make is to move it from the shared adapter to an ado subadapter, since you are calling ado specific methods. While ado is currently the only adapter using the shared access adapter, it's possible that other adapters will may use the shared access adapter in the future (I seem to remember a jdbc adapter that handled Access, but can't find it).

Let me go ahead and make the changes, which will be pushed sometime today. After that, you can send another pull request for the foreign_key_list and/or tables if you feel like implementing those.

Thanks for all of your help!

@ericgj
Contributor
ericgj commented Sep 5, 2012

OK, great. I had thought about putting this in the ADO adapter for the reasons you mention, but I hesitated because my sense is that OpenSchema is kind of a fake standard -- that is, different ADO providers interpret its conventions in very different ways. It seemed like potentially a big thicket to wade into without finding out more. And also not sure how likely MS is to drop support for it in future versions, though I guess that's always a risk no matter what.

@jeremyevans jeremyevans merged commit 6e5542a into jeremyevans:master Sep 5, 2012
@jeremyevans
Owner

I've merged your branch moving the code to an ado subadapter, with some minor changes. Please check it and make sure it still works for you (it does for me). Thanks!

@ericgj
Contributor
ericgj commented Sep 5, 2012

Works for me, thanks. Will work on the foreign_key_list and tables and setting up some basic ADO adapter tests, when I free up some time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment