Eric's excellent article takes a comprehensive look at various ways to generate keys while offline. In our application we used a combination of composite keys and shorter unique IDs (a timestamp) because our data was clustered around users and chances of collisions was small.
As for access control we found that it is best to manage this on the server as you would for an online application. When it comes to emulating this when disconnected you can dispense with much of the access control and sharing rules as long as you give each user their own private slice of the database that was downloaded based on the access control rules you built into the server. Just be sure that you key all data with a user id in the local data base because you can't be sure each user will get their own database. If they login as a separate users in Windows they will get their own database but if two people share the same Windows account they will be using the same database. This happens all the time so you do need to implement a login if you have access control rules around your data. I would not worry too much about off line considerations for licensing. As long as the user has to register at some point which requires the server you should be able to implement licensing of your application entirely on the server. On Sep 24, 7:38 am, dkrumholz <[EMAIL PROTECTED]> wrote: > Just getting started with Gears, I have some conceptual questions - > > 1. If I have an offline database and add a parent record with a db > generated key and then child records with that key - how does the > server db prevent collisions between my keys and another user's > offline keys? > > 2. What is the best way to allow a limited number of users (some not > all) to share data? Do I need to rely on server data and build the > user access requirements into the app? > > 3. What is the best method to grant and restrict access that allows > for licensing of apps?
