I need advice on disconnected clients

  • Thread starter Thread starter Peter Morris [Droopy eyes software]
  • Start date Start date
P

Peter Morris [Droopy eyes software]

Hi all

I want to develop a client which only connects to a server in order to
synchronize data. The idea is that the user will see a smaller view of the
whole database (only items relevant to themself) and may then add new items,
update, delete, etc. Eventually connecting to a middle tier which checks
their changes and sync's with the main database.

I don't want the user to be online and have to "check out" items first, they
should just be able to edit them immediately and then go through some kind
of reconciliation process.

Is ADO .NET the technology to use? Can I enforce some minor business
constraints on the client using ADO .NET? Does ADO .NET have a "prohibit"
for a delete rule, I see cascade etc but no prohibit?

Does anyone know of any good resources I can look at? Articles, components,
etc?

Thank you very much
 
You might want to consider implementing data rules on the data tier.
If you are using SQL Server, you can design tables with an "owner"
column, and stored procedures which will return only rows that a user
owns. Similarly, create stored procedures for all data interactions,
and revoke permissions for users to interact directly with the tables.
You can also implement MT business rules and method-level security as
well. The advantage of implementing rules on the data tier is that
they can't be circumvented by other applications or connections.

--Mary
 
Hi
You might want to consider implementing data rules on the data tier.
Click to expand...

Sorry if I wasn't clear. I meant "Can I *additionally* enforce some minor
business constraints on the client". I intend to perform all validations on
the server, but would also like to be able to perform some constraint
validation on the client so that errors may be trapped earlier.

Pete
 
ADO.NET is much lighter than ADO in many respects. It's simply a pathway to
the data--as it should be.
My approach to this problem is to use Extended Properties to store rules and
criteria that need to be enforced on the client. These can be assigned to
any object in the database (assuming you're using SQL Server). They can be
called anything and you can put anything (almost) in them. When the client
starts, it reads the EPs and tunes its constraints to match. I wrote an
article on this some time ago. See
http://www.betav.com/sql_server_magazine.htm.

hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Absolutely -- you can and should take this approach. All validation
should ideally occur on the client first, so as not to waste a round
trip to the server just to get back a gratuitous error message.
Validation on the server is your last-ditch data protection. There are
different approaches you can take on the client, based on whether it's
a winforms or web forms UI. If it's a web app, you can put validation
in server controls or in client-side script as well as in your code.

--Mary
 
Back
Top