I'm actually looking back over the materials Microsoft published and I'm
very confused. First, I'm definitely interested in implementing the support.
However, it seems like MS says to use an nvarchar(34) for DateTimeOffset. I
have a database in front of me though (replicated from SQL Server 2008 via
the Sync Framework) that has columns of type DateTime with offsets in them.
So I'm not really sure how this works. Maybe its a facade over nvarchar(34)?
If the date math functions like datepart and datediff work with strings,
though, this could be how it works. I need to investigate further.

And I'm definitely interested in implementing this -- that's why I posted on
the dev list instead of on the users list, actually. :-)

If anyone wants to help or can possibly figure out what I'm confused about,
any assistance is appreciated.

Thanks,
David

On Tue, Sep 14, 2010 at 6:22 AM, Richard Brown (gmail) <
[email protected]> wrote:

>  Hi David,
>
> It doesn't look like the CE dialect ever got that type registered.  You can
> sub-class the dialect and call RegisterColumnType to extend the existing
> dialect.
>
> Patches are also welcome if you wish to raise a JIRA ... you can
> investigate the tests that Dario committed in rev 4011 as a guide.
>
>  *From:* Dario Quintana <[email protected]>
> *Sent:* Tuesday, September 14, 2010 11:15 AM
> *To:* [email protected]
> *Subject:* Re: [nhibernate-development] DateTimeOffset broken with SQL CE?
>
> Hi,
> IIRC DateTimeOffSet is available to use with SQL 2008 dialect
>
> On Mon, Sep 13, 2010 at 12:22 AM, David Pfeffer <[email protected]>wrote:
>
>> Hello,
>>
>> SQL CE has supported since version 3.5 SP1 (SP2 is current) time
>> offsets. The DateTime type supports both offset-less times as well as
>> times with offsets.
>>
>> However, the mapping seems to be all weird. When I use a DateTime to
>> map to the DB, everything is fine, but when I use a DateTimeOffset, I
>> get an error --
>>
>> {No mapping exists from DbType DateTimeOffset to a known SqlDbType.}
>
>
>
>
> --
> Dario Quintana
>
>

Reply via email to