Re: private Deploy of SQL CE 3.1



[Resending again, as old send fail. Pardon me if it reaches the newsgroup
twice]

Hey space_cowboy,

Did you read this blog post:
http://blogs.msdn.com/sqlservercompact/archive/2009/04/01/after-moving-the-database-from-one-platform-to-other-the-first-sqlceconnection-open-takes-more-time.aspx

Basically SQL CE interop between desktop and device started only with
version v3.1 and *not* v3.0.

Windows XP and Windows CE give same Sort Key (or have same NLS Version)
so indexes are valid across platforms. With Windows Vista (don't know about
Win 7), index data is not valid any more across platform and there is a
need to rebuild the indexes. Now this index rebuilding is available only
from v3.1 onwards.

Thanks,
Laxmi


"space_cowboy" <spacecowboy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:2D306C28-A6B3-4CB6-A435-1471F7E952B2@xxxxxxxxxxxxxxxx

I will post the final ourcome of this adventure once I get to the bottom
of
it with MS.


"Ginny Caughey MVP" wrote:

I don't actually know why the registry entries are there. I also
privately
deploy SqlCe DLLs for a couple of desktop apps that use SqlCe and never
had
any issues, and I have customers running a mix of Xp and Vista as well
as
various server versions. (One app runs on servers.)

One thing that has simplified life for me is always using the most
current
version of SqlCe on desktop and device, so I don't think you should
dismiss
that approach unless you've tested it yourself. Hopefully your users
won't
be seeing a lot of error messages, and you can programmatically upgrade
a
database to 3.5 if you need to. Besides, the newest versions always have
the
most bug fixes. I thought it was a great idea when Windows Mobile first
started including SqlCe in ROM, but now I find the version I want to use
for
my app is always a newer one than whatever is in ROM, no matter how
recent
the devices are.

Sorry I can't help with Platform Builder.

--

Ginny Caughey
Device Application Development MVP



"space_cowboy" <spacecowboy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3D56FBB1-4C9B-406D-A8AD-4BC11AE3F80F@xxxxxxxxxxxxxxxx
Thanks Ginny,

I am not meaning to put you on the spot. I shipped out my CE products
with
3.0 dll's, and my desktop App that manipulates the sdfs consumed by
the CE
device uses 3.1 dlls. All was fine as long as my desktop app was
running
on
XP. Well recently the desktop app started moving to newer OS's (vista
and
7)
by the users. Once the files were modified by the newer os's and
copied to
the CE device, they are somewhat perceived as corrupted by the CE
device.
Currently I have a support case going with MS where they are trying to
address the issue, but putting 3.1 engine(dll's) on the device appears
to
fix
the inter-op or cross-platform issues.
I am not ready to make the 3.5 jump (wihtout being asked questions to
death
by the users about error messages.) So putting the 3.1 engine on the
device
seems to be the least intrusive option. Still not sure if my
architecture
was
flawed to begin with (mixing the 2 revs of dlls across the desktop
.net
app
and the CE device .net app.) Experience is definitely showing this to
be
the
case. But I wish there was more concrete docs to have veered me off
this
course right off the bat. Maybe someone else can answer the platform
builder
issue.


I noticed that if one follows the private-deploy doc for the desktop
as
described in
http://technet.microsoft.com/en-us/library/bb219481(SQL.90).aspx
it not only copies the DLL's to the install dir, but also makes reg
entries
for the various unamanged dlls, which just copying the files as you
have
suggested will of course not do. Any idea if there is any value to
those
reg
entries?




"Ginny Caughey MVP" wrote:

I haven't worked with Platform Builder, so I don't really know. But I
have a
lot of experience with trial and error in general. ;-) If what you're
attempting to do isn't documented somewhere and somebody else hasn't
done
it...

--

Ginny Caughey
Device Application Development MVP



"space_cowboy" <spacecowboy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:C6344AF4-5153-4B55-9201-F418324B41D0@xxxxxxxxxxxxxxxx

I also found that in Platform builder when I removed "sql mobile"
and
"sql
mobile .net 2.0 data provider" catalog items, that took away at
least
on
dependent catalog item that was needed for the privately deployed
3.1
dll's
to work properly. in particular "cocreateguid functionality for
ole32."
Without this catalog item, the privately deployed dlls, in
particular
System.data.sqlserverce.dll kept throwing "cant pinvoke
sqlceme30.dll
exception". Are there any other depedencies that you are aware of
in my
image
as far as sqlserver that my architecture is not barfing on now, but
may
later.

"space_cowboy" wrote:

Ginny,

Thanks for your reply.
I guess what I am concerned about is that the cabs were
registering
some
of
the unmanaged dlls, without which some of the cocreate calls from
within
the
unmanaged dlls could fail. This I can not verify, because the
source
for
SQL
dll's unlike the OS code is unavailable.

"Ginny Caughey MVP" wrote:

space_cowboy,

Yes all you have to do is copy the DLLs, and your app may not
even
need
all
8 of them. I privately deploy my SqlCe DLLs with my apps, but I
use
a
single
cab containing my app along with the SqlCe DLLs to do it as I
find
that
more
convenient than deploying a bunch of separate files.

--

Ginny Caughey
Device Application Development MVP



"space_cowboy" <space_cowboy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:4A66ABF8-5209-4CB3-855F-0319F599FD9C@xxxxxxxxxxxxxxxx
Hello,

Since there is no catalog item in "platform builder for
windows ce
5.0"
for
sql compact 3.1, I would like to just copy the necessary DLL's
to
my
application folder and run from there. I would also like to
stay
away
from
installing the provided cabs. My question is will it be enough
to
copy the
8
dll's to my application directory? Or are there more things
being
done by
the
cab (like registry mods) that I should be cautious about. In a
basic
test
my
installation works. That is, my application can create a conn
and
do
updates,
and get values to an SDF. Am I missing something by doing it
this
way
instead
of using cabs?

Te eight dll' are of file version 3.0.5300.0
sqlceca30.dll
sqlcecompact30.dll
sqlceer30EN.dll
sqlceme30.dll
sqlceoledb30.dll
sqlceqp30.dll
sqlcese30.dll
System.Data.sqlserverce.dll










.



Relevant Pages

  • Re: private Deploy of SQL CE 3.1
    ... my app is always a newer one than whatever is in ROM, ... device uses 3.1 dlls. ... All was fine as long as my desktop app was ... I privately deploy my SqlCe DLLs with my apps, ...
    (microsoft.public.sqlserver.ce)
  • Re: private Deploy of SQL CE 3.1
    ... my app is always a newer one than whatever is in ROM, ... device uses 3.1 dlls. ... All was fine as long as my desktop app was ... I also found that in Platform builder when I removed "sql mobile" ...
    (microsoft.public.sqlserver.ce)
  • Re: private Deploy of SQL CE 3.1
    ... Windows XP and Windows CE give same Sort Key ... my app is always a newer one than whatever is in ROM, ... device uses 3.1 dlls. ... I also found that in Platform builder when I removed "sql mobile" ...
    (microsoft.public.sqlserver.ce)
  • Re: private Deploy of SQL CE 3.1
    ... I also privately deploy SqlCe DLLs for a couple of desktop apps that use SqlCe and never had any issues, and I have customers running a mix of Xp and Vista as well as various server versions. ... I thought it was a great idea when Windows Mobile first started including SqlCe in ROM, but now I find the version I want to use for my app is always a newer one than whatever is in ROM, no matter how recent the devices are. ... and my desktop App that manipulates the sdfs consumed by the CE ...
    (microsoft.public.sqlserver.ce)
  • Re: private Deploy of SQL CE 3.1
    ... and my desktop App that manipulates the sdfs consumed by the CE ... device uses 3.1 dlls. ... I guess what I am concerned about is that the cabs were registering some ...
    (microsoft.public.sqlserver.ce)

Loading