>>>>>>If you can get passed the storage problem then I'd guess that the biggest problem, if multiple users are updating data off-line, would be synchronizing back to the server.......
>>>>>
>>>>>You see, I am creating an application that will be used by many customers (even though right now only one is willing to beta test it). In my experience every customer will require a different approach. Some may be willing to work with a data sub-set. Others will say, "I want it all and I want it now" :) And as I mentioned, I see so many issues in making the application work off-line (mainly because the pages are all ASP.NET web forms and the code is in the code behind) that I gave up on the idea of working completely off line. I will still store all various lookup tables to the local storage so that the pages load faster (rather then going to the database on every new page). But as far as this particular feature, I am concerned that the data storage will be a problem. This is why I am inclined to store it on the web server. And the user will load it from the server rather than from the local Storage.
>>>>
>>>>Well you could always write a IPad or Android app version - that will give you 4GB for data (more on IPad) :-}
>>>
>>>Shoot.. how come I didn't think of that. Thank you for the suggestion :))) (have you ever tried to write an app for iOS or Android?)
>>
>>Currently doing a Android version of the off-line web app.....
>>Whole new paradigm to take in - but at least Java is fairly similar to C#
>
>My hat off to you. The problem I have is that my beta tester already committed to iPad mini. And developing for iOS is a completely different ball game; I think.

Supposing that there already is a lot of web logic/interface designed, I'd look first either into Nativescript or Cordova(Phonegap) to create an app where the "app" focus is storage space mostly and GUI is handled by traditional Web design - similar to VFP handling Web type GUI with WebBrowser, you can re-use a lot of web GUI in those tool sets.