History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: NH-124
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Major Major
Assignee: Mike Doerfler
Reporter: Robert Warriner
Votes: 2
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
NHibernate

MS Access Dialect and Driver

Created: 17/Sep/04 09:49 AM   Updated: 20/Jan/05 09:04 PM
Component/s: Data Providers
Affects Version/s: prealpha
Fix Version/s: None


 Description  « Hide
The OleDb command object fails to prepare when the FROM stmt uses multiple JOIN commands.

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Robert Warriner - 17/Sep/04 09:50 AM
I have worked on this issue on my local copy of NH. Apparently MS Access expects the joins to be nested within parens. Refactored join building code to include open and close parens for each join. Still testing, and not sure if it will work for other dialects.

Mike Doerfler - 25/Oct/04 12:07 AM
copied from NH-108

Require access to MS Access 2000 DBs from NH. The GenericDialect is not capable because of issues with OLEDB command strings/parameters. I have previously created a MSAccessDialect class based on the MSSQLServerDialect and seem to be working fine. There is probably some fine tuning that will need to be accomplished to make it fully work with NH. Will upload the code later.

copied from NH-123

When using a OleDb connection to an Access database (using a custom Access2000 Dialect) the command object does not recognize the use of "case" statements. When the case statement is used, the command object fails during the preparation phase.

I have fixed this issue with my local copy of NHibernate by specifying that the command object use the IF construct (rather than case). I don't know if this will work with other dialects (other than Access) though.

Martijn Boland - 30/Oct/04 09:02 AM
Hi all,

Yesterday I gave it it shot and tried to make a decent MsAccessDialect. To my surprise, Access does support quite a lot of features via OleDb (decent DDL, Identity, more datatypes) so I started to get a good feeling about it. The dialect is more or less finished now, but there are still some major issues:

- No support for Int64: it is possible to use BIGINT in your schema but Access still creates a 32 bit integer. I used Decimal(19,0) instead of BIGINT to let more unit tests pass, but this is obviously no solution. Just don't use Int64 types with Access.

- Special characters: Access freaks out when table or field names contain !.[] (even when quoted). Don't use them. I changed some of the field names in the unit test hbm.xml's to get things working, but that's just temporarily.

- The @#$% join syntax: it's very hard to create a JoinFragment because of the parentheses on those weird places. This is currently the main issue. It needs a syntax like

SELECT A.blah1, B.blah2, C.blah3
FROM A INNER JOIN B (INNER JOIN C ON C.FK_b = B.PK) ON B.FK_a = A.PK

or

SELECT A.blah1, B.blah2, C.blah3
((FROM A INNER JOIN B ON B.FK_a = A.PK) INNER JOIN C ON C.FK_b = B.PK)

Anybody has a clue if this is possible with NH?

- Parameter lengths with OleDb: Copy and pasted the MsSql code to generate a parameter and it works.

- SELECT @@IDENTITY: Changed IdentifierGeneratorFactory.Get(). Access returns a value of the type object (MsSql returns a decimal). Replaced
    decimal identityValue = rs.GetDecimal(0);
with
    object identityValue = rs.GetValue(0);
and it works. Didn't test on MsSql but I think it should als work.

That's it. If the join issues can be solved, we have a usable MsAccess dialect (and improved OleDb driver :))

Martijn

Mike Doerfler - 20/Jan/05 09:04 PM
An AccessDialect has not been contributed and would have many limitations.