ADO.net

  • Thread starter Thread starter Rizwan Ahmed
  • Start date Start date
R

Rizwan Ahmed

Hey,
i am bit concerned about the architecture
provided in the .net frame work for ado.net.
The disconnected architecture does nor serves you best on
the desktop application. As you are not connected to
database and if any other changes the table in the
database you are not notified or your side data is still
older one.
As it was not in ADO we use to set the recordset
properties to our need and we were quite happy. but not
now.
Example:
Dim rs as ADODB.Recordset
TextBox1.databindings.add("Text",rs,"id") (X)
which is not allowed by the .net frame work, as i am
using the Recordset that is in ADO not in ADO.Net and its
required interface is not present.
But i want to do that ... as it is quite easy to
use this structure. I think there is problem with
Microsoft they dont even support there ADO properties in
their .net TextBox or any other control.
They should provide the Implementation of
connected recordset or simply implement the IList
interface or any other interface that is required for the
data binding in .net fram work.

thanx,

Rizwan Ahmed
 
Rizwan:

ADO.NET is defintely geared more toward distributed and disparate
architecture than stand alone islands. I can't really speak for MS, but I'm
guessing taht they are betting that the future isn't in stand alone apps.
ADO.NET can get you where you need to go, and you can definitely write extra
high quality desktop apps with it. Do you need to rush out and adopt
ADO.NET for apps that will only ever be desktop DB types? No. But the
later you embrace it, the more you restrict yourself in future scalability.

You can still use ADO.NET in a connected fashion with DataReaders and many
of the command objects methods. YOu can populate many different structures
to bind to, like collections or arraylists. You can also implement binding
to datasets very easily.

There are tons of examples out there, but you cn definitely get where you
need to be with ADO.NET


Cheers,

Bill
 
A good textbook will help you understand why it is not a
good idea to hold DB locks while the user is having tea.
Since you are concerned about the data changing in the
mean time, you must be using transactions?

Also, check out "optimistic locking" and the resolution
of update conflicts in the SQL Server Online help.
 
Back
Top