I need to knock up a very quick prototype/proof of concept application to demo to someone within the next couple of days so I've minimal time to research this as fully as I normally would. The set-up is a very simple database application running on a laptop - will only ever be a single user updating a couple of tables so I was thinking of knocking up a basic Win Forms app against SQL Compact. Visual Studio's auto generated data grid edit screens will be fine with a little customisation. The second aspect is to then add a windows mobile client application that can pull data from both tables stored on the laptop, edit some data and insert some extra rows before sending the changes back to the laptop copy of the database.
I've not done any WinMo development so what's the best approach for me to look at. Is it easy enough to sync data between the two databases when the WinMo device is connected to the laptop with USB?
Most of the samples I've looked at so far seem to be syncing SQL Compact with SQL Standard using IIS which seems a bit overkill. The volumes of data to be synced are so small that I can easily write some manual sync code if it's easy for me to query/update the Compact DB from the laptop application when the device is connected.
Edit:
I've seen mention that a quick and easy solution is to use RAPI - when the device is connected copy the DB to the laptop, connect and do the necessary magic and then copy it back to the device. Any problems with this approach? This is a single laptop user with a single mobile device user to sync up so it's pretty basic stuff. In any single sync the volume of updates is likely to be less than 10 records.
Take a look at Microsoft's Sync Framework. The have examples of synchronizing SQLCE as well as contact data. The Sync Developer Center page has loads of info as well.
Trying to do this manually is not fun. It sounds easy, but once you get into things like collision detection, precedence, transactions, guaranteed delivery and loads of other stuff you'll find it really isn't as straightforward as you might think.
EDIT
If your scenario really is as easy as you say (i.e. it's not really a sync, but a data copy) then yes, RAPI is probably the easiest mechanism if ActiveSync exists and is acceptable as part of the solution. It's nice because you don't have to write the transport infrastructure, and if what's in the box in't enough, you can always write custom RAPI extensions.
Related
i am making a WPF program. This program has a database and dataset. The software is working great on the computer i made the program on. Today I tested the software on another PC. But it was not working because it couldn't find the SQL server.
So that is a problem. I thought it was local so I can use it everywhere but that is not the case.
What i want is a database that is portable, so can be used on every computer and it works offline. I don't know where to start and hope someone can give me some tips
You can copy an MDF file around using SQL Server LocalDB (formerly known as CE - Compact Edition).
SQLite is a good option, too. That's what it was made for. Libraries can be found on their homepage here or on Nuget here.
A connection string for the MDF option would look like this:
Server=.\SQLExpress;AttachDbFilename=|DataDirectory|mydbfile.mdf;Database=dbname; Trusted_Connection=Yes;
More connection strings can be found here:
https://www.connectionstrings.com/sql-server-2008/
https://www.connectionstrings.com/sqlite/
Another option to consider is not to use a database at all.
Serialisation and deserialization objects to files is often way faster than any of the database options.
Serialisation is best suited when your data is not hugely dynamic or you're saving multiple relatively discrete chunks.
I coverted an app from win ce to serialisation a while ago. It significantly speeded up as a result.
Made much more of a difference than I expected.
And of course you can use linq to xml to query filter sort etc.
You can mix this with a message queue such as ms mq and persist the dynamic part of your data you're capturing to disk in a queue.
Consider a salesman with an occasionally connected app on a laptop.
They could load fairly static data such as product options and costs as xml. Deserialise that in the app so they can put a quote together.
They then need to persist the quotes.
You could just serialise each quote as a separate file and it'd fly.
Or you could persist them using message queue.
Have a windows service which looks for when the laptop connects to wi fi.
When connected it gets each of the quotes off the queue and sends them to head office by calling a web service.
I am working on a Windows 8.1 app which should work offline and online and it should connect to a database in both of the situation . So which kind of service or database I should implement to allow access to local and remote database and sync when it goes online.
There's not much tooling available to help you in your scenario. You can probably get the most out of Microsoft Sync framework, but you need to bear in mind that there's no official support for WinRT from Microsoft, nor is the framework further developed in its current form.
I suggest you take a look at SyncWinRT which is an open source library that can be used together with Microsoft Sync framework to make it work on Windows Phone and Windows Store apps. It's not all that easy to setup (neither is Sync framework itself) and there are some limitations, but depending on your requirements it might work for you.
Taking a broader look at your situation, there are 3 approaches which you can take:
Have your application work directly with the remote database when online and with local database when offline, but make it work the same in both scenarios otherwise: this is the most tricky to do, because you need to be able to switch between the two DALs (data access layers) based on the mode and also be able to sync your local database with the remote one when you get back online. For switching the DALs you might want to take a look at CSLA.NET which in general has such capabilities, but its learning curve is quite high. For synchronizing the two databases the above mentioned SyncWinRT should work for you.
Have your application always work with the local database copy which you synchronize with the remote one on user request: in this case you would have the same data structure locally as it is remotely, but your local business logic would always use the local database. This way you only need one DAL and the user can synchronize the data when he is online. Again for the synchronization you could use SyncWinRT, the rest will just be a standard app with local SQLite database which you can develop as you see fit.
Have custom local data structure and synchronization process: completely customize the mobile experience by giving control of data synchronization to the user. He should be aware what data he is synchronizing when preparring for the offline work and synchronize that data back when he is done. The local data structure can be tailored for this and the synchronization will have to be done completely manually, but you can make it more simple if you control the actual use cases.
In my experience the last option usually works best both for users and for the developers. Although it seems to be more work, you can avoid a lot of conflicting scenarios by having closer control over the user options. And even the users might like the simpler wizard like experience better than a copy of their original online one.
I am developing a windows application for agricultural purpose. This application will be used by multiple users to maintain the data. The main issue is there won't be network connectivity on the work location. But however by end of the day they can go and synchronize if there are any option.
I just want to know how can we import and store all the data locally and update the data to database when there is network.
The options that i thought is to have SQL on every machine that runs this application. Store the data to local database when there is no network.
Having a separate button to export the local data to the centralized database when there is network.
Looks like this is complicated. Is there any better and easier option.
I prefer using c#, Visual studio.
Thanks.
You can use SQLite for storing data locally. It's fast, lightweight, and public domain.
You can use whatever the database of choice for the centralized server.
Well, this a quite broad question, as it has many options and scenarios. The questions you should ask yourself are:
Does user handle new information only or any information from any other user from the previous syncing?
Do you have to handle update conflicts?
Do you handle text information only or you have complex types and binary files?
As for the solution, the easiest way, from my point of view, would be using SQL Lite on portable devices, is a lightweight SQL client that will allow you to handle information easily. On the server you can use whatever you want, SQL Server, MySQL or any other SQL flavor you may like. Just make sure there is a connector for your portable device OS.
If you keep thinking of using SQL server on the portable device, it's a battery hogger!!!, you might want to check Microsoft Sync framework, as it provides almost all possible scenarios for handling data syncing, manage conflicts, etc.
Thanks for the answers. Please find the below solution that we implemented.
1) Installed SQL express on all the local machines
2) Used Microsoft Sync framework to sync the data. The sync is configured on demand.
Issues faced:
1) We were using geometry datatype on few tables and this was not supported by sync framework.
2) Any change in the database schema will not reflect on the client machine. We will have to delete all the system generated procedures used to track the table change and regenerate it. I am sure there will be a much better way to do this.
Cheers,
Jebli
I am currently in the process of developing a program and not sure where to go from here...
I am using Visual C# and the DotSpatial frawework in order to do the GIS/GPS side of things but am unsure of what back end database to use.
I have had a look at PostgrSQL with PostGIS and also had a look at MSSQL as this now has Geospatial capabilities.
So what I am trying to achieve is the following with the software:
- The software needs to be used both at the persons desk, but also remotely while using the GIS/GPS side of the system to track the users travelling. (i.e. when locating where they need to go - this is custom data on remote sites). This is relatively easy to do with DotSpatial alone and not DB is needed.
- They have custom forms that capture data (text, lats/longs, photos) while out on site.
- The data needs to be able to sync up with the main database when they are back in the office
- This data needs to be viewable by everyone connected to the system once the system is updated
Ultimately if this can be a type of DMS then that would be great. So I am keeping that in mind as well.
Should I use a seperate DB for the datacapture side of things and something else for the main DB or should I use the same for both? Which one is easiest to configure? I would prefer when deploying the software that the installation goes smootly and dont have to manually configure each machine.
The main server is Windows 2008 Server btw.
Any help or suggestions would be greatly appreciated.
I use PostgreSQL with PostGIS on a daily basis. Although it is opensource it provides very good funcionality and performance.
Check this Cross Compare between SQL Server 2008 Spatial, PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6. This could give you a good idea
I second the recommendation for PostgreSQL/PostGIS. It works very well and is well supported by the community. I would note that OpenStreetMap uses PostGIS as well. Indeed, if you ever want to work with their data you'll be wanting PostgreSQL.
I will be building an in-house, Occasionally Connected App (OCA). What technologies would you suggest I employ.
Here are my parameters:
.NET Shop(3.5sp1)
C# for code behind (winform,wpf,silverlight)
SQL Server Backend (2005 or possibly 2008 pending approval)
Solo Developer
Solo SQL Administrator
Low Tech end users
Low bandwidth to 5 Branch offices
This is a LOB app but not a POS.
Majority of users have laptops that they take to Member's Home
The Data for this App is stored in 5 separate Databases, though in one SQL instance.
I am looking for specific recommendations on which path to choose. Merge Replication or Sync Framework database synchronization providers? SQL Express or SQL CE at the Subscriber? Can I use LINQ to SQL for the DAL?
Is a Silverlight 'Offline/Out of Browser App' Example Here, feasible?
This is my first LARGE business application so any experienced comments are welcome.
As requested here is some additional info on the type of Data. My users are Nurses and Social Workers who go to Member's homes and create "Plans" or "Health Assessment Reviews" for them. These are things like a Medication List or a List of there current "Providers". Steps to achieve members' goals or a list of there current/past Diagnosis's. Things like that.
Also the typical Members Name, Address, Phone Number, etc. Mostly this is a Data Storage and Retrieval app that facilitates reporting. Very little "processing" takes place and Nurses and Social Workers work in teams that are assigned members so I usually have very little crossover or potential data conflicts. Nurses and SW's also are responsible for different area's of the MCP(Member Centered Plan)
Additional question; Is Sync Framework really only a viable option if I can use SQL 2008? Seems that way due to the Change Tracking etc....thoughts?
Once you solve the problem of change detection and data movement, everything else is trivial. In other words technologies like WPF, Silverlight, Forms and even WCF are orthogonal to your main problem and your choice should be based on your personal preferences and experience. The real hard nut to crack is working disconnected and synchronizing changes. Which leaves two out-of-the-box avenues: Synch Framework or Replication.
I would say, for your scenario, definetely Synch Framework. Merge replication, like all forms of replication, is designed for systems that are connected continously with intermitent disconnects. And most critically replication can work only over static names. Laptops connecting from various hot-spots and ISPs have a nasty habit of changing FQ names with each connection. Replication can overcome this only if a VPN of sort is used and VPN is usually a major support issue. Replication is just not designed for the high mobility of OCA systems.
Synch Framework will pretty much force you to SQL 2008 back end because of the need to Change Data Capture or Change Tracking, both being SQL 2008 only features.
You will still have plenty of hard problems to solve ahead (authentication, versioning and upgrade, data conflict resolution policies, securing data on the client for accidental media loss etc etc)
Personally, I would say:
.NET 3.5
WCF Data Services (for communication between the client app and your data)
SQL Server 2k5/2k8 (whichever you can use)
Silverlight w/ Out of Browser Functionality
VistaDB (to store data locally on the client until you can push to the server)
use unique-identifier for key if you are creating stuff while offline and not connected and when you do connect, updating the database.
this is going to be way easier than using auto-increment key
Having worked on an occasionally connected application, I'd encourage you to look in to SQL Server CE for the client machines, with Sync Services to handle the connections. Here is a good tutorial.
You could create this stuff from the ground up, it seems.
However, this seems an awful lot like a CRM application, and it wouldn't surprise me if you could find an enterprise software package to do this without starting from scratch and instead modify one of the configurations to meet your business rules.
In a previous life, I was a configuration developer for this thing called Siebel that might be close to what your'e looking for. They even have a built-in synchronization tool called Siebel Remote.
It might be a cheaper route to go than rolling your own from scratch.
I wrote an order taking program for wine sales reps. Here is the video. The client software is installed using click-once. That also installs SQL Server Express and loads the database. I used the Microsoft Sync Framework to sync the local database with the one on the server (see the last section of the video.)
With powerful clients now I don't see any reason to not use SQL Server Express, it is free with a limit of 4GB.
SQL CE had too many limitations - no stored procs being a major one.
You will need to use GUIDs everywhere as the primary key - see the new NewSequentialID().
I love click-once, it is a big time saver.
I'm looking forward to Silverlight, but just haven't had time to look into it. Not sure if I would have done it with Silverlight if doing it now or not.
Having said all this, this is not a project for anyone inexperienced. So I would also get some very experienced help.