On Thu, Dec 31, 2009 at 01:55, Daniel Rail <dan...@accra.ca> wrote:
> What happens if someone uses another type for bools? As an example, I

As far as there's a default conversion to .NET bool, it's OK.

> usually use CHAR(1) with the values "T" and "F". If it can be

This will not work. .NET recognizes True and False as string
representation of bool.

> And, I could almost say the same for GUIDs, as some might be storing
> them in a VARCHAR(32), in another charset than OCTET. I currently use
> ECO and the GUID field is stored in a VARCHAR(32) UTF-8 field.

Maybe this will work, if the string is valid for Guid ctor. But
there's couple of "hacks" in provider's code to recognize guids and
transparently work with it, and it's also checking charset. Anyway,
you can try it. Just use the GetGuid value.

> I would suggest, if it's possible, to simply give a warning to the
> developer that #BOOL# and TIMESTAMP don't match, but still let the

Warnings around EF designer are handled by EF itself. I cannot do much here.

> developer use that combination.  And, if an error occurs in runtime,
> then the developer will realize that it wont work.

OK. Every opinion counts.

-- 
Jiri {x2} Cincura (CTO x2develop.com)
http://blog.cincura.net/ | http://www.ID3renamer.com

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Reply via email to