ADO.Net Disconnected Database

[Guest]

We are architecting a system in .Net which will use a VB.Net Windows form client and Web Services. The system will be quite extensive with well over 100 screens and about 120 tables. We will also be building a disconnected laptop version of the system that will include about 2/3 of the full system functionality. We have an old system that uses SQL Server Merge Replication and MSDE on the laptops, but it has been wrought with synchronization problems. We would like to look into using ADO.Net exclusively on the laptops without a database. Since more then one laptop will connect to the detached data source, we have come up with a strategy of handling concurrency in ADO.Net using DataViews and Remoting. We will have to build our own low level database functionality including locking and checkpoints.

My question is, are we trying to do too much with ADO.Net? Is there anyone out there that has created a full functional “database†exclusively in ADO.Net?

 

[Miha Markic]

My question is, are we trying to do too much with ADO.Net? Is there

anyone out there that has created a full functional "database" exclusively
in ADO.Net?

Hi Fred,

Why don't you use a database server(MSDE, Access or whatever) on the laptop
just for disconnected data?
You can manually synchronize it with master server.
Plus, it will give you all the functionality you are trying to build on
ado.net.

 

[William Ryan]

There are many effective strategies in ADO.NET to handle concurrency. Merge
Replication isn't a problem. YOu can implement checkpoints and the like
through Stored Procs and server side functions, and ADO.NET does support
transactions so that won't be a problem.

Anyway, check out David Sceppa's book on ADO.NET (the ADO.NET Core
Reference) or head over to www.betav.com and check out some of Bill Vaughn's
stuff, that will give you a good background on ADO.NET. At the end of the
day, you can accomplish just about anything you need with ADO.NET.

We are architecting a system in .Net which will use a VB.Net Windows form

client and Web Services. The system will be quite extensive with well over
100 screens and about 120 tables. We will also be building a disconnected
laptop version of the system that will include about 2/3 of the full system
functionality. We have an old system that uses SQL Server Merge Replication
and MSDE on the laptops, but it has been wrought with synchronization
problems. We would like to look into using ADO.Net exclusively on the
laptops without a database. Since more then one laptop will connect to the
detached data source, we have come up with a strategy of handling
concurrency in ADO.Net using DataViews and Remoting. We will have to build
our own low level database functionality including locking and checkpoints.

My question is, are we trying to do too much with ADO.Net? Is there

anyone out there that has created a full functional "database" exclusively
in ADO.Net?

 

[William \(Bill\) Vaughn]

Consider that ADO.NET is not a DBMS. It's a thin (thinner than ADO classic)
data access interface. It has the ability to persist to XML locally or to
query against virtually any DBMS. I've mentored a number of companies that
are designing similar systems. MSDE can be a viable local DBMS and many
companies are replicating to a base server with a lot of success. Perhaps I
can help further...

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
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.
__________________________________

We are architecting a system in .Net which will use a VB.Net Windows form

client and Web Services. The system will be quite extensive with well over
100 screens and about 120 tables. We will also be building a disconnected
laptop version of the system that will include about 2/3 of the full system
functionality. We have an old system that uses SQL Server Merge Replication
and MSDE on the laptops, but it has been wrought with synchronization
problems. We would like to look into using ADO.Net exclusively on the
laptops without a database. Since more then one laptop will connect to the
detached data source, we have come up with a strategy of handling
concurrency in ADO.Net using DataViews and Remoting. We will have to build
our own low level database functionality including locking and checkpoints.

My question is, are we trying to do too much with ADO.Net? Is there

anyone out there that has created a full functional "database" exclusively
in ADO.Net?

 

[Scott M.]

What do you base that statement on?

 

[William \(Bill\) Vaughn]

ADO classic included significantly more logic to manage server-side state
including updatable, scrollable, cached local or server-side cursors. ADO
classic created action queries on the fly based on the Update Criteria
property. It also had a disconnected model that was the forerunner to
ADO.NET's disconnected DataSet.

Is this a "better" approach? Not necessarily--it's just different. ADO.NET
is better suited for ASP.NET architectures where managing server-side state.
It places far more control in the hands of the developer who must create
their own action queries at runtime or settle for the very limited
CommandBuilder. It exposes a low-level interface (the DataReader) that was
hidden from developers in ADO classic.


--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
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.
__________________________________

 

[Scott M.]

I understand what ADO.NET is and its advantages over ADO. I just disagree
that ADO.NET is a "thinner" object model than ADO. While ADO did manage
server and client cursors, there were fundamentally only 4 objects in the
model (Connection, Command, Parameter, Recordset).

ADO.NET (as you know) has many more objects (each with its own interface)
that exposes functionality like never before. The DataAdapter alone is 4
commands and a DataReader all rolled into one.

I just wouldn't describe ADO.NET as a thinner model than ADO, that's all.

 

[William \(Bill\) Vaughn]

I didn't say thinner object model. I said thinner in the sense that it does
less and requires more programming on the part of the developer to get it to
do updating. For some developers this is a big advantage, for others this is
a problem as they never learned how to write an Update statement--it was
simply done for them.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
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.
__________________________________