Can't use DbProviderFactory in compact framework?

  • Thread starter Thread starter enantiomer
  • Start date Start date
E

enantiomer

I am using the DbProviderFactory in my services project (a class
library) to do all of my database interactions. I use this because
people may want to use a variety of different databases. I have been
using this for my windows forms project and it seems to be working
fine.

I am now looking at creating a device application that would ideally
use my services project to interact with what would probably be a sql
server 2005 mobile database. It seems as though the DbProviderFactory
is not actually included in the compact framework. This seems strange
because in the System.Data.Common namespace, almost all of the other
database agnostic classes still exist. Since this is the case, this
means that I won't be able to make calls to my services (as a project
reference), since every database interaction utilizes the
DbProviderFactory??? Is this right? I tried to do this and visual
studio 2005 wouldnt even let me add the reference since it said that
the reference isn't a device project...

If this is the case, then what should I do in order to still utilize
those services that I wrote to interact with the database? I suppose I
could use web services to get and insert my strongly typed business
objects to and from the database, but this will be slower and i can't
rely on my mobile device always being connected.

Any advise on this issue? Why is it that the DbProviderFactory isn't
included in the compact framework? Thanks,

Jonathan
 
enantiomer said:
I am using the DbProviderFactory in my services project (a class
library) to do all of my database interactions. I use this because
people may want to use a variety of different databases. I have been
using this for my windows forms project and it seems to be working
fine.
Click to expand...
--You can get to the same place without using the class as such, but If you
really want to use this specific method, I'd use Peter's code
http://www.inthehand.com/library/InTheHand.Data.Common.DbProviderFactory.html -
everything he writes is superb.

It isn't however supported in the compact framework.
I am now looking at creating a device application that would ideally
use my services project to interact with what would probably be a sql
server 2005 mobile database. It seems as though the DbProviderFactory
is not actually included in the compact framework. This seems strange
because in the System.Data.Common namespace, almost all of the other
database agnostic classes still exist. Since this is the case, this
means that I won't be able to make calls to my services (as a project
reference), since every database interaction utilizes the
DbProviderFactory???
Click to expand...
--DBProviderFactory isn't supported in the CF
Is this right? I tried to do this and visual
studio 2005 wouldnt even let me add the reference since it said that
the reference isn't a device project...
Click to expand...
--You can still create your own class implementing a factory pattern and
since the number of providers that you'd realistically be dealing with is
minimal you can easily code around this even though it's not going to be
truly discoverable
If this is the case, then what should I do in order to still utilize
those services that I wrote to interact with the database? I suppose I
could use web services to get and insert my strongly typed business
objects to and from the database, but this will be slower and i can't
rely on my mobile device always being connected.
Click to expand...
--You can still write and handle your objects locally and then only what you
have connectivity, move the data. This can be a complex issue though so
there's not one single answer, it really depends on your scenario
Any advise on this issue? Why is it that the DbProviderFactory isn't
included in the compact framework?
Click to expand...
--For the same reason a lot of stuff isn't included in the CF. You should
hear the grief MS gets every time the footprint gets on byte bigger. They
could stuff the entire framework on a PDA if they really wanted to (well,
perhaps that's a little much but you get my drift) but it's a balancing act
between what different groups want. Say that they included it and it
increased the footprint to a size that impedeed older PDAs. This would
cause a lot of anger and may even stop adoption for many shops. Compare
that with leaving it out. You are free to write it yourself and include,
which puts a little burden on the developer but causes the least amount of
damage to everyone involved. Footprint is a HUGE issue with device
development and since PDAs and devices are much smaller than desktops, a lot
of tradeoffs have to be made. Also, there is a rather limited set of device
databases. Well, let me rephrase that - the market is dominated by a few
major players namely Sql Server CE, Sql Mobile, Pocket Access (which isn't
supported by the compact framework although Peter does have a great library
for it to) and Oracle Lite. Compare this with what you have in most desktop
or server scenarios and the distinction becomes profound.

HTH,

Bill
Thanks,
 
Back
Top