[AccessD] Data interface The best way

We use typed datasets and build a data "entity" in the solution that
inherits that typed dataset and handles validations, update calls,
fills, etc.  We build dataproviders for each typed
dataset/entity/interface and let it handle creating the connections and
command strings, building the data adapter and passing a filled "entity"
back to the calling routine.  We actually store the SQL for these
commands in xml and look up the one we need, passing the parameters in
through the dataprovider.  It works quite well. 

Our code doesn't distinguish between back ends because right now, we're
simply using the OleDb provider for everything.  The SQL provider might
be faster, but we would have to write separate code to implement it and
our app needs to be able to work against either backend so we're
husbanding our resources<g>.

Charlotte Foust


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
Sent: Thursday, October 13, 2005 10:09 AM
To: 'Access Developers discussion and problem solving'
Subject: [AccessD] Data interface The best way


Hi All:

I am current working building a .Net solution for a client. ASP.Net 2,
ADO.Net and MS SQL 200x. 

Traditionally, when designing the system I have passed all the Selects,
Inserts, Updates and Deletes requests through to the server via ADO
commands using parameter lists and then to MS SQL side Stored Procedures
to manage any final validation and data work.

I am not sure of the best way to manage the data flow with this new
architecture (i.e. Datasets etc.). Any suggestions and experiences would
be very helpful.

TIA
Jim 

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com