Re: private Deploy of SQL CE 3.1


Laxmi,

Thank you for your response.
When I said "Vista DB", I meant SQLCE SDF file that was openend in Vista,
and so had its indexes rebuilt in Vista with 3.1 drivers, and my problem was
that when this SDF came to my CE 5.0 device with 3.0 drivers, since
rebuilding was not getting done, I was running into all kinds of exceptions
in the device.




"Laxmi Narsimha Rao Oruganti [MSFT]" wrote:

Hey space_cowboy,

As you rightly figured out that we do rebuild indexes during full
compaction (of course, we do other activities as well). But this
rebuiliding is what we do in v3.1 on NLS version mismatch. So, I think it
is
a good and right idea to have the database compacted before using on the
platform where the database is copied to.

I did not understand that VistaDB part though!. I guess you are using
both Vista DB and SQL CE for different needs. This forum is just for SQL
Server Compact (or SQL CE) and hence I can not
answer anything related to Vista DB.

Repair operation does the similar set of operations on the destination
database as that of Compact operation. However, since Repair is generally
called when database is corrupt, it would be doing
many checks on source database as it would be doubting almost all :(.
Theoritically, Repair would be slower when compared to Compact. Be aware of
that fact, and chose. If you are sure that you
can live with that small perf gap, then I think you are good to go.

Thanks,
Laxmi

"space_cowboy" <spacecowboy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:B791A508-2F95-45EB-9B0A-96CFC783408E@xxxxxxxxxxxxxxxx
Laxmi,

I came up with an idea today that would possible address my inter-op
issues
between 3.0 drivers in the device(ce 5.0) and 3.1 driver on the
desktop(vista/xp/7). The SDF has always been kept at 3.1 (3.0.3600.0
build)
because we were never previously doing anything to change the DB on the
device(no compacting/repairing). The desktop always does compacting. All
my
tests so far pose this as a favorable solution. I want to know if you see
any
flaws in this solution. Since I have many desktop apps and devices out
there
in the field, I am trying to not have to upgrade neither the desktop nor
the
device to 3.1 or 3.5 drivers . I would like to leave the architecture as
is.
So my plan is to just programmatically compact the DB's in 3.0 device when
they first come from the desktop, and this will rebuild the indexes, which
is
where most of my probs were coming from (the device perceiving the Vista
DB's
to be corrupt).

2nd question is do you know if Repair operation does index-rebuilding just
like Compact operation? It appeared so from my testing, but I wasnt sure.
The
thing I like about possibly doing repair is that it will not change the DB
itself into a 3.0 db.

-Thanks


"Laxmi Narsimha Rao Oruganti [MSFT]" wrote:

Thanks for the reply. As far as I am aware, COM and OLE are the main
dependencies for device platform. For desktop, you need to be careful
about
x64 story and ErikEJ blog post (which the blog post points to).

Thanks,
Laxmi

"space_cowboy" <spacecowboy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:06EE8F66-C191-4D80-ADA0-DF4AE5B1BA0F@xxxxxxxxxxxxxxxx
Laxmi,

I know you have addressed the "cant pinkvoke sqlceme30.dll" issue
pretty
in-depth. Thank you again. When I removed the "sql mobile and sql
mobile
.net
data provider" catalog items in my platform builder, built a new CE
image
with no SQL componnets in it, and tried just coying the 3.1 dll's to
the
application directory, I was getting those pinvoke errors on
sqlceme30.dll
from sysem.data,sqlsrvercer.dll. This message was popping up eventhough
the
dll sqlceme30.dll was sitting right there in the app directory. I
found
out
that this message went away and everything was working fine once I
added
the
"cocreateguid functionality for ole32" catalog item which was taken
away
once I removed the 3.0 catalog components, because it is one of the
dependencies. I had the COM catalog item, but not that other one. I had
the
full blown COM catalog item, but not that paricular associated item.
Are
you
aware of any other core depndencies that the 3.1 dll's have? Or if I am
opening the connection to the db and reading/writing to it
successfully, I
can ASSume that I have all the necessary catalog items?


"Laxmi Narsimha Rao Oruganti [MSFT]" wrote:

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
.

Relevant Pages

  • Re: 2003 Repair / Compact Problem
    ... I managed to compact/repair and build an ADE without incident several times ... Administrator" should have any impact. ... Currently I have Windows Vista UAC turned off, therefore not sure, without ... repair & compact my 2003 .adp files. ...
    (microsoft.public.access.adp.sqlserver)
  • Re: We apologize for the inconvenience, but Windows did not start successfully.
    ... In Vista, there is a startup repair option that can be reached by booting the disk that achieves the same thing as using bcdedit. ... In this type of install, essentially a clean install to a new folder, the existing installation is move to a windows.old folder on the root of the drive where data can later be recovered from. ... Another option is to boot the Vista disk and load the Recovery Console, then run rstrui.exe to load system restore and try a point prior to the failure. ... If this was XP I would first rebuild the boot. ...
    (microsoft.public.windows.vista.installation_setup)
  • Re: Search not finding specific files
    ... One thing that seems to help the Vista search function is to periodically rebuild the search index. ... Control Panel| Classic View| Indexing Options| Advanced| Rebuild. ... wanting to search my Invoices folder for all invoices to a particular ...
    (microsoft.public.windows.vista.file_management)
  • Re: Outlook missing msvcr80.dll error, downloaded it still wont st
    ... OL2003 and higher are compatible with Vista ... It used to work before I had to execute the factory ... I am also not running Norton and removed it immediately after the rebuild as ...
    (microsoft.public.outlook.general)
  • Rebuild under Vista
    ... I upgraded to Vista a few months ago and was happy to see that my ... ancient 16-bit MicroFocus-SP2 software runs as happily as it did under ... I seldom use Rebuild since I rarely have problems with files. ... I recently ran Rebuild (at the command prompt) and got "not a valid ...
    (comp.lang.cobol)
Loading