 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
SQL Server Forum / DB Engine / SQL Server CE / July 2009private Deploy of SQL CE 3.1
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 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.  SignatureGinny Caughey Device Application Development MVP > Hello, > [quoted text clipped - 23 lines] > sqlcese30.dll > System.Data.sqlserverce.dll 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. > space_cowboy, > [quoted text clipped - 30 lines] > > sqlcese30.dll > > System.Data.sqlserverce.dll 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. > Ginny, > [quoted text clipped - 38 lines] > > > sqlcese30.dll > > > System.Data.sqlserverce.dll 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... SignatureGinny Caughey Device Application Development MVP > 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 [quoted text clipped - 61 lines] >> > > sqlcese30.dll >> > > System.Data.sqlserverce.dll 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? > 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 [quoted text clipped - 66 lines] > >> > > sqlcese30.dll > >> > > System.Data.sqlserverce.dll 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. SignatureGinny Caughey Device Application Development MVP > Thanks Ginny, > [quoted text clipped - 119 lines] >> >> > > sqlcese30.dll >> >> > > System.Data.sqlserverce.dll I will post the final ourcome of this adventure once I get to the bottom of it with MS. > 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 [quoted text clipped - 136 lines] > >> >> > > sqlcese30.dll > >> >> > > System.Data.sqlserverce.dll Hey space_cowboy, Did you read this blog post: http://blogs.msdn.com/sqlservercompact/archive/2009/04/01/after-moving-the-datab ase-from-one-platform-to-other-the-first-sqlceconnection-open-takes-more-time.as px 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 > I will post the final ourcome of this adventure once I get to the bottom > of [quoted text clipped - 180 lines] >> >> >> > > sqlcese30.dll >> >> >> > > System.Data.sqlserverce.dll Hi Laxmi, I have read that blog of yours many a times , and thank you for that. I cant help grinding my teeth reading the article, especially when I see the date on the post. I started developing my design of 3.1 on the deskop ad 3.0 on the device in 2007 with product launch in 08. I wish and here was nothing at the ime indicating that there was a known inter-op problem, and soon I had a bunch of these SDF's running around with people carrying the problem with them. All I remember, and I apologize for the steaming, is MS's sales pitch of "your data anywhere, anytime" when 3.1 came out. > Hey space_cowboy, > [quoted text clipped - 197 lines] > >> >> >> > > sqlcese30.dll > >> >> >> > > System.Data.sqlserverce.dll 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? > Hey space_cowboy, > [quoted text clipped - 197 lines] > >> >> >> > > sqlcese30.dll > >> >> >> > > System.Data.sqlserverce.dll 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 > Laxmi, > [quoted text clipped - 254 lines] >> >> >> >> > > sqlcese30.dll >> >> >> >> > > System.Data.sqlserverce.dll 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 > 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 [quoted text clipped - 242 lines] > >> >> >> >> > > my > >> >> >> >> > > installation works. That is, my application can create a 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 > Laxmi, > [quoted text clipped - 317 lines] >> >> >> >> >> > > my >> >> >> >> >> > > installation works. That is, my application can create a 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. > Hey space_cowboy, > [quoted text clipped - 251 lines] > >> >> >> >> > on > >> >> >> >> > dependent catalog item that was needed for the privately [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-datab ase-from-one-platform-to-other-the-first-sqlceconnection-open-takes-more-time.as px 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 >> I will post the final ourcome of this adventure once I get to the bottom >> of [quoted text clipped - 193 lines] >>> >> >> > > sqlcese30.dll >>> >> >> > > System.Data.sqlserverce.dll [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-datab ase-from-one-platform-to-other-the-first-sqlceconnection-open-takes-more-time.as px 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 >> I will post the final ourcome of this adventure once I get to the bottom >> of [quoted text clipped - 193 lines] >>> >> >> > > sqlcese30.dll >>> >> >> > > System.Data.sqlserverce.dll |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.