It is just me or has MS created some of the worst ways to access and display
data?
You can use a DataSet, but if you want to sort or filter the data to must
use a DataView which is created from a DataSet.
But, if you sort by using the Grid (clicking the header) you can no longer
use the DataSet (or maybe the DataView, if that is what you are using) to
locate the record that the user has selected!!
You have to write code to get the current position...this should just be a
property!!
Also, can someone explain to me why does the FindRows return
DataRowView...what can you do with a DataRowView, I haven't figure out a way
to load this data into a new DataView or a DataSet (if there is a way,
please explain it to me). It seems that the FindRows should have just
return a new DataView!!
I understand why all of the necessary data access components are broken out
into many different parts, but why not ALSO build a component that
encompasses all of the components and use that as an "enhanced DataSet" that
can also be used as a Datasource to the grid and other components.(This is
something that I have already done for myself.)
Maybe it's because I'm coming from Borland and expect top notch development
tools/comopnents...where there VCL Framework and Data Access components were
THE BEST!!!
But I had to leave Borland because their management said that they were
killing the Borland C++ Builder (BCB) product about 6 months ago. But, they
just recently announced that they had a change of heart and will now support
BCB.
That's a little to flaky for me, so I jumped ship and moved to MS.
But with what I have seen in VS.NET (C#), I might have to talk my chances
with Borland.
49  3137 
If anything I think your complaint applies to the DataGrid component - not
ADO.NET.
Actually, you can bind a grid to all sorts of stuff - inlcuding a strongly
typed collection. dataViews are actually based on DataTables not datasets.
There's nothign stopping you from subclassing the grid to get the
functionality that you want. "It should just be a property" I guess,
unless you want multiselect which would entail two properties - or one that
you would need to iterate through.
The DataRowView is necessary b/c it can show four different states of the
datarow - Default - Current, Original and Proposed which can be very handy
particularly in a disconnected scenario where you want to show users the
original value and the stuff they changed - or just want to show them the
changed rows.
DataTable.Select for instance will give you an array of the rows that are
found - which in turn can be used to bind to a grid. This may be helpful.
You can set the RowFilter of a DataView to whatever search conditions you
want so only those show.
I admit the dataGrid for Winforms leaves a little to be desired, but again
this has Nothing to do with ADO.NET. I think you'll find it's easy enough
to write a few of your own controls (or use Infragistics for instance) that
you can reuse and tailor to your particular needs.
HTH,
Bill
--
W.G. Ryan MVP (Windows Embedded)
TiBA Solutions www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
"Relaxin" <me@yourhouse.com> wrote in message
news:eP**************@TK2MSFTNGP15.phx.gbl... It is just me or has MS created some of the worst ways to access and
display data?
You can use a DataSet, but if you want to sort or filter the data to must
use a DataView which is created from a DataSet.
But, if you sort by using the Grid (clicking the header) you can no longer
use the DataSet (or maybe the DataView, if that is what you are using) to
locate the record that the user has selected!!
You have to write code to get the current position...this should just be a
property!!
Also, can someone explain to me why does the FindRows return
DataRowView...what can you do with a DataRowView, I haven't figure out a
way to load this data into a new DataView or a DataSet (if there is a way,
please explain it to me). It seems that the FindRows should have just
return a new DataView!!
I understand why all of the necessary data access components are broken
out into many different parts, but why not ALSO build a component that
encompasses all of the components and use that as an "enhanced DataSet"
that can also be used as a Datasource to the grid and other components.(This is
something that I have already done for myself.)
Maybe it's because I'm coming from Borland and expect top notch
development tools/comopnents...where there VCL Framework and Data Access components
were THE BEST!!!
But I had to leave Borland because their management said that they were
killing the Borland C++ Builder (BCB) product about 6 months ago. But,
they just recently announced that they had a change of heart and will now
support BCB.
That's a little to flaky for me, so I jumped ship and moved to MS.
But with what I have seen in VS.NET (C#), I might have to talk my chances
with Borland.
You may find this link helpful as well http://weblogs.asp.net/codemouse/
--
W.G. Ryan MVP (Windows Embedded)
TiBA Solutions www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
"Relaxin" <me@yourhouse.com> wrote in message
news:eP**************@TK2MSFTNGP15.phx.gbl... It is just me or has MS created some of the worst ways to access and
display data?
You can use a DataSet, but if you want to sort or filter the data to must
use a DataView which is created from a DataSet.
But, if you sort by using the Grid (clicking the header) you can no longer
use the DataSet (or maybe the DataView, if that is what you are using) to
locate the record that the user has selected!!
You have to write code to get the current position...this should just be a
property!!
Also, can someone explain to me why does the FindRows return
DataRowView...what can you do with a DataRowView, I haven't figure out a
way to load this data into a new DataView or a DataSet (if there is a way,
please explain it to me). It seems that the FindRows should have just
return a new DataView!!
I understand why all of the necessary data access components are broken
out into many different parts, but why not ALSO build a component that
encompasses all of the components and use that as an "enhanced DataSet"
that can also be used as a Datasource to the grid and other components.(This is
something that I have already done for myself.)
Maybe it's because I'm coming from Borland and expect top notch
development tools/comopnents...where there VCL Framework and Data Access components
were THE BEST!!!
But I had to leave Borland because their management said that they were
killing the Borland C++ Builder (BCB) product about 6 months ago. But,
they just recently announced that they had a change of heart and will now
support BCB.
That's a little to flaky for me, so I jumped ship and moved to MS.
But with what I have seen in VS.NET (C#), I might have to talk my chances
with Borland.
>It is just me or has MS created some of the worst ways to access and display data?
It's just you! :-) Hey, you almost *ASKED* for that! ;-)
Seriously, ADO.NET might not be totally intuitive at first, but it
really rocks - it packs a LOT of power!
You can use a DataSet, but if you want to sort or filter the data to must
use a DataView which is created from a DataSet.
You can use a DataView (based and created from a *DataTable* - not a
DataSet - watch your terms!! You gotta be EXACT to get things right!)
to sort and filter the data in any way, shape or form.
Heck, you can have your data stored in a DataTable, and look at it
through a dozen different data views - filtering and sorting to your
hearts' content! How powerful is that?
Also, can someone explain to me why does the FindRows return
DataRowView...what can you do with a DataRowView, I haven't figure out a way
to load this data into a new DataView or a DataSet
A DataRowView is just like a DataRow - only for a view. If you need
the underlying DataRow, just grab it from the .Row property of the
DataRowView - how easy is that?
I really think you ought to put a bit more brain power into learning
and understanding ADO.NET - you haven't grasped all the power behind
it just yet! Read a book, read the online help, study the samples -
it'll be worth it!
Marc
================================================== ==============
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
Marc,
It's just you! :-) Hey, you almost *ASKED* for that! ;-)
Why you wrote that. (I first did want you to give an answer and than answer
that again with). "It was only that I could not now".
:-)
Cor ----- Original Message -----
From: "Marc Scheuner [MVP ADSI]" <m.********@inova.SPAMBEGONE.ch>
Newsgroups: microsoft.public.dotnet.general
Sent: Tuesday, December 28, 2004 11:00 PM
Subject: Re: Database access sucks!
A DataRowView is just like a DataRow - only for a view. If you need
the underlying DataRow, just grab it from the .Row property of the
DataRowView - how easy is that?
That is exactly my point, why not just have FindRows return a DataView!!
I really think you ought to put a bit more brain power into learning
and understanding ADO.NET - you haven't grasped all the power behind
it just yet! Read a book, read the online help, study the samples -
it'll be worth it!
I have and I've used the best. I also used and created components from
OLEDB.
ADO.NET has alot to be desired and they are also missing functionality that
OLEDB had.
Such as the different resultset types (Keyset, dynamic, forwardonly,
etc...).
With the .NET dataset, it forces you to load all of the data to the
client...this doesn't work so well when you database is mainly made up of
images!
I hate it when the vendor (MS) tells me how I should write my code by
removing functionality and not replacing it with something similar.
----- Original Message -----
From: "Marc Scheuner [MVP ADSI]" <m.********@inova.SPAMBEGONE.ch>
Newsgroups: microsoft.public.dotnet.general
Sent: Tuesday, December 28, 2004 11:00 PM
Subject: Re: Database access sucks! It is just me or has MS created some of the worst ways to access and
display
data?
It's just you! :-) Hey, you almost *ASKED* for that! ;-)
Seriously, ADO.NET might not be totally intuitive at first, but it
really rocks - it packs a LOT of power!
You can use a DataSet, but if you want to sort or filter the data to must
use a DataView which is created from a DataSet.
You can use a DataView (based and created from a *DataTable* - not a
DataSet - watch your terms!! You gotta be EXACT to get things right!)
to sort and filter the data in any way, shape or form.
Heck, you can have your data stored in a DataTable, and look at it
through a dozen different data views - filtering and sorting to your
hearts' content! How powerful is that?
Also, can someone explain to me why does the FindRows return
DataRowView...what can you do with a DataRowView, I haven't figure out a
way
to load this data into a new DataView or a DataSet
A DataRowView is just like a DataRow - only for a view. If you need
the underlying DataRow, just grab it from the .Row property of the
DataRowView - how easy is that?
I really think you ought to put a bit more brain power into learning
and understanding ADO.NET - you haven't grasped all the power behind
it just yet! Read a book, read the online help, study the samples -
it'll be worth it!
Marc
================================================== ==============
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
Relaxin,
Probably is your major mistake although you are not writing it, that you
compare a dataset with a recordset, what is not the case. A recordset is
comparable with a datatable.
The datatable has a lot of extra's above the recordset by instance a
dataview, with can show you data in a lot of ways. This newsgroup is not the
part to show all advantages from a datatable above a recordset.
And not to tell that there are only advantages in some cases can the
standard optimistic concurrency in my opinion be a disadvantage, however
modern disconnected use makes pessimistic concurrency in my opinion very
hard to do and should only be done when it is really needed
To select one or more datarows from a datatable you can use the
datatable.select
You can as well find a row in the datarow collection in a datatable by using
a datarowcollection.find
Or get a selection by using the dataview.rowfilter
Or get a position of a datarow in a dataview by the dataview.find
You can use as well of course to narrow your datatable the different select
where clauses.
Maybe you can say it was more simple with the recordset because it had not
all those possibilities. The same as people who went from the T Ford to a
more advantage car. The T Ford was well made however nobody forced those
people to use another car.
Just my thought,
Cor
The datatable has a lot of extra's above the recordset by instance a
dataview, with can show you data in a lot of ways. This newsgroup is not
the part to show all advantages from a datatable above a recordset.
A recordset is comparible to a datatable (in your example) if you are going
to use the dataset to create the dataview.
You could also use other oledb components and functions to sort, filter,
etc.. to create the same "dataview" "like" data.
So you are making a mute point here.
And not to tell that there are only advantages in some cases can the
standard optimistic concurrency in my opinion be a disadvantage, however
modern disconnected use makes pessimistic concurrency in my opinion very
hard to do and should only be done when it is really needed
And where are you coming up with this "pessimistic concurrency", I have
always used optimistic concurrency.
In fact OLEDB allowed you to use SQL Servers rowversion (1 field) as a
method to update a record.
ADO.NET will use a WHERE clause of all of the columns within your SELECT
statement.
This is a very inefficient why to update a record!
To select one or more datarows from a datatable you can use the
datatable.select
You can as well find a row in the datarow collection in a datatable by
using a datarowcollection.find
Or get a selection by using the dataview.rowfilter
Or get a position of a datarow in a dataview by the dataview.find
You can use as well of course to narrow your datatable the different
select where clauses.
Maybe you can say it was more simple with the recordset because it had not
all those possibilities.
Your statements are "trying" to limit my argument to the recordset, but you
have used a DataSet, DataTable, DataView and a DataRowCollection!!
Lets be fair about this, OLEDB and ADO.NET are both comprised of classes and
the classes are designed to work together, except MS has removed alot of
functionality from some of the ADO.NET classes.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:Oc**************@tk2msftngp13.phx.gbl... Relaxin,
Probably is your major mistake although you are not writing it, that you
compare a dataset with a recordset, what is not the case. A recordset is
comparable with a datatable.
The datatable has a lot of extra's above the recordset by instance a
dataview, with can show you data in a lot of ways. This newsgroup is not
the part to show all advantages from a datatable above a recordset.
And not to tell that there are only advantages in some cases can the
standard optimistic concurrency in my opinion be a disadvantage, however
modern disconnected use makes pessimistic concurrency in my opinion very
hard to do and should only be done when it is really needed
To select one or more datarows from a datatable you can use the
datatable.select
You can as well find a row in the datarow collection in a datatable by
using a datarowcollection.find
Or get a selection by using the dataview.rowfilter
Or get a position of a datarow in a dataview by the dataview.find
You can use as well of course to narrow your datatable the different
select where clauses.
Maybe you can say it was more simple with the recordset because it had not
all those possibilities. The same as people who went from the T Ford to a
more advantage car. The T Ford was well made however nobody forced those
people to use another car.
Just my thought,
Cor
Relaxin,
I get more and more the idea that you don't know what is a dataset,
datatable, datarow, dataview and/or a datarowview in ADONET. Can you explain
what they are in your opinion.
Because when we talk about different things it is hard to make a discussion.
Cor
I know EXACTLY what they are, but since you asked for it.
The DataSet contains 1 or more DataTables.
A DataTable contains 1 or more DataRows.
A DataRow contains 1 or more DataColumns.
A DataView is a subset and/or sorted view of the DataSet.
I'm still unsure what the purpose of the DataRowViews is, but I know
DataRowView.FindRows returns it.
Like I mentioned earlier, I have created my own components to handle things
the way they should be.
I'm mainly venting because I would have expected a better design from MS,
but I guess if you(most people in this NG, I assume) haven't seen anything
other than MS, you wouldn't have anything to compare it to.
So of course you would think that this design is great.
Give Borland a try when you get a chance, you will see a hell of a design.
You can tell that Borland tools are Developed By Developers for Developers.
MS is designed for cash only!!
"Cor Ligthert" <no************@planet.nl> wrote in message
news:Oq**************@TK2MSFTNGP09.phx.gbl... Relaxin,
I get more and more the idea that you don't know what is a dataset,
datatable, datarow, dataview and/or a datarowview in ADONET. Can you
explain what they are in your opinion.
Because when we talk about different things it is hard to make a
discussion.
Cor
Relaxin I know EXACTLY what they are, but since you asked for it.
The DataSet contains 1 or more DataTables
references 0 or more
A DataTable contains 1 or more DataRows
references 0 or more.
A DataRow contains 1 or more DataColumns.
A DataRow references 0 or more Items described by the columncollection from
the DataTable
A DataView is a subset and/or sorted view of the DataSet.
The DataView is a view on a datatable not on the Dataset (as you
consequently state) which has filters and sort parameters in it. Every
DataTable contains one Dataview named DefaultView.
I'm still unsure what the purpose of the DataRowViews is, but I know
A DataRowView is a view on an single datarow however as well on other class
objects
DataRowView.FindRows returns it.
I don't know the DataRowView.FindRows method so I do not know what you mean
with this.
I don't think that your first statement about EXACTLY is very correct.
Just my thought,
Cor
"Relaxin" <me@yourhouse.com> wrote in message
news:eP**************@TK2MSFTNGP15.phx.gbl... It is just me or has MS created some of the worst ways to access and
display
data?
You can use a DataSet, but if you want to sort or filter the data to must
use a DataView which is created from a DataSet.
But, if you sort by using the Grid (clicking the header) you can no longer
use the DataSet (or maybe the DataView, if that is what you are using) to
locate the record that the user has selected!!
You have to write code to get the current position...this should just be a
property!!
Also, can someone explain to me why does the FindRows return
DataRowView...what can you do with a DataRowView, I haven't figure out a
way
to load this data into a new DataView or a DataSet (if there is a way,
please explain it to me). It seems that the FindRows should have just
return a new DataView!!
I understand why all of the necessary data access components are broken
out
into many different parts, but why not ALSO build a component that
encompasses all of the components and use that as an "enhanced DataSet"
that
can also be used as a Datasource to the grid and other components.(This is
something that I have already done for myself.)
Maybe it's because I'm coming from Borland and expect top notch
development
tools/comopnents...where there VCL Framework and Data Access components
were
THE BEST!!!
But I had to leave Borland because their management said that they were
killing the Borland C++ Builder (BCB) product about 6 months ago. But,
they
just recently announced that they had a change of heart and will now
support
BCB.
That's a little to flaky for me, so I jumped ship and moved to MS.
But with what I have seen in VS.NET (C#), I might have to talk my chances
with Borland.
Hello Relaxin,
I'm sorry, I don't have time to go into details. Here are some references:
Microsoft® ADO.NET Step by Step http://www.microsoft.com/mspress/books/4825.asp
Microsoft® ADO.NET (Core Reference) http://www.microsoft.com/mspress/books/5354.asp
Professional ADO.NET http://www.amazon.com/exec/obidos/tg...books&n=507846
It would be good to learn and fully understand ADO.NET on an academic level
before trying to use it in a commercial project. Unless your employer
allows you to learn the as you go.
ADO.NET is not perfect, but there was a lot of thought that went into
architecting it and rest assured that there is a solution for most of the
problems you'll run into.
J. Buelna - Houston, TX
Why don't you try using LLBLGen Pro ( www.llblgen.com). I find it much
easier to use then the default way of data access.
Have a nice New Years Eve,
Michel van den Berg
Relaxin wrote: It is just me or has MS created some of the worst ways to access and display
data?
You can use a DataSet, but if you want to sort or filter the data to must
use a DataView which is created from a DataSet.
But, if you sort by using the Grid (clicking the header) you can no longer
use the DataSet (or maybe the DataView, if that is what you are using) to
locate the record that the user has selected!!
You have to write code to get the current position...this should just be a
property!!
Also, can someone explain to me why does the FindRows return
DataRowView...what can you do with a DataRowView, I haven't figure out a way
to load this data into a new DataView or a DataSet (if there is a way,
please explain it to me). It seems that the FindRows should have just
return a new DataView!!
I understand why all of the necessary data access components are broken out
into many different parts, but why not ALSO build a component that
encompasses all of the components and use that as an "enhanced DataSet" that
can also be used as a Datasource to the grid and other components.(This is
something that I have already done for myself.)
Maybe it's because I'm coming from Borland and expect top notch development
tools/comopnents...where there VCL Framework and Data Access components were
THE BEST!!!
But I had to leave Borland because their management said that they were
killing the Borland C++ Builder (BCB) product about 6 months ago. But, they
just recently announced that they had a change of heart and will now support
BCB.
That's a little to flaky for me, so I jumped ship and moved to MS.
But with what I have seen in VS.NET (C#), I might have to talk my chances
with Borland.
What I need is a connected resultset within the confines of a DataSet.
My database is full of images, and as you could imagine, this is a painful
process when they are all loaded to the clientside.
Anyone with any knowledge in this area?
"J. Buelna - Houston, TX" <jbuelna-not@microsoft...yet.com> wrote in message
news:OT**************@TK2MSFTNGP11.phx.gbl...
"Relaxin" <me@yourhouse.com> wrote in message
news:eP**************@TK2MSFTNGP15.phx.gbl... It is just me or has MS created some of the worst ways to access and
display
data?
You can use a DataSet, but if you want to sort or filter the data to must
use a DataView which is created from a DataSet.
But, if you sort by using the Grid (clicking the header) you can no
longer
use the DataSet (or maybe the DataView, if that is what you are using) to
locate the record that the user has selected!!
You have to write code to get the current position...this should just be
a
property!!
Also, can someone explain to me why does the FindRows return
DataRowView...what can you do with a DataRowView, I haven't figure out a
way
to load this data into a new DataView or a DataSet (if there is a way,
please explain it to me). It seems that the FindRows should have just
return a new DataView!!
I understand why all of the necessary data access components are broken
out
into many different parts, but why not ALSO build a component that
encompasses all of the components and use that as an "enhanced DataSet"
that
can also be used as a Datasource to the grid and other components.(This
is
something that I have already done for myself.)
Maybe it's because I'm coming from Borland and expect top notch
development
tools/comopnents...where there VCL Framework and Data Access components
were
THE BEST!!!
But I had to leave Borland because their management said that they were
killing the Borland C++ Builder (BCB) product about 6 months ago. But,
they
just recently announced that they had a change of heart and will now
support
BCB.
That's a little to flaky for me, so I jumped ship and moved to MS.
But with what I have seen in VS.NET (C#), I might have to talk my chances
with Borland.
Hello Relaxin,
I'm sorry, I don't have time to go into details. Here are some
references:
Microsoft® ADO.NET Step by Step
http://www.microsoft.com/mspress/books/4825.asp
Microsoft® ADO.NET (Core Reference)
http://www.microsoft.com/mspress/books/5354.asp
Professional ADO.NET
http://www.amazon.com/exec/obidos/tg...books&n=507846
It would be good to learn and fully understand ADO.NET on an academic
level before trying to use it in a commercial project. Unless your
employer allows you to learn the as you go.
ADO.NET is not perfect, but there was a lot of thought that went into
architecting it and rest assured that there is a solution for most of the
problems you'll run into.
J. Buelna - Houston, TX
ok, 0 or more.
I guess you found the loophole you were looking for.
Have a great day!
"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl... Relaxin
I know EXACTLY what they are, but since you asked for it.
The DataSet contains 1 or more DataTables
references 0 or more
A DataTable contains 1 or more DataRows
references 0 or more.
A DataRow contains 1 or more DataColumns.
A DataRow references 0 or more Items described by the columncollection
from the DataTable
A DataView is a subset and/or sorted view of the DataSet.
The DataView is a view on a datatable not on the Dataset (as you
consequently state) which has filters and sort parameters in it. Every
DataTable contains one Dataview named DefaultView.
I'm still unsure what the purpose of the DataRowViews is, but I know
A DataRowView is a view on an single datarow however as well on other
class objects
DataRowView.FindRows returns it.
I don't know the DataRowView.FindRows method so I do not know what you
mean with this.
I don't think that your first statement about EXACTLY is very correct.
Just my thought,
Cor
Hello Relaxin,
apart from your last statement, which was a bit unfair, you are not wrong in
your description of the object tree for a dataset. That said, datasets are
part of a disconnected data retrieval model that is far more scalable than
the prior database tools. By the way, you bashed MS for the new structure,
and referred to Borland, but MS created the older structure too. Seems odd
to bring Borland into it at all.
Certainly, you can create "chatty" data interaction models that will do the
exact same thing as "keyset". The rest of the retrieval types are perfectly
available in ADO.NET, if you know how to use it. While I may take a
different tone that Cor, I would have to say that he has a point: there is
very little useful functionality "lost" in ADO.NET.
From what I've heard, the product teams were getting a lot of heat because
the prior stuff had serious scalability problems. The responses were
something along the lines of "If the feature looks good, but leads to
serious problems later, why is it there? Remove it now and save us the
pain. We have to live with this stuff." MS was simply responding to the
express needs of their base. If the make a little money along the way...
good. That's called capitalism.
Back to technology.
If you have images in some of your columns, don't return those columns in
your dataset. Use a select statement or a stored proc to select only the
rows that you need for your non-image processing, and then when you need an
image, ask for it from the database using a seperate statement. It's what
the older tools used to do for you, but at least this way, the code is
yours, so you are at more liberty to tweak it to get the performance you
need.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Relaxin" <me@yourhouse.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... I know EXACTLY what they are, but since you asked for it.
The DataSet contains 1 or more DataTables.
A DataTable contains 1 or more DataRows.
A DataRow contains 1 or more DataColumns.
A DataView is a subset and/or sorted view of the DataSet.
I'm still unsure what the purpose of the DataRowViews is, but I know
DataRowView.FindRows returns it.
Like I mentioned earlier, I have created my own components to handle
things the way they should be.
I'm mainly venting because I would have expected a better design from MS,
but I guess if you(most people in this NG, I assume) haven't seen anything
other than MS, you wouldn't have anything to compare it to.
So of course you would think that this design is great.
Give Borland a try when you get a chance, you will see a hell of a design.
You can tell that Borland tools are Developed By Developers for
Developers.
MS is designed for cash only!!
"Cor Ligthert" <no************@planet.nl> wrote in message
news:Oq**************@TK2MSFTNGP09.phx.gbl... Relaxin,
I get more and more the idea that you don't know what is a dataset,
datatable, datarow, dataview and/or a datarowview in ADONET. Can you
explain what they are in your opinion.
Because when we talk about different things it is hard to make a
discussion.
Cor
Nick,
My tone changed (and even not aggressively) after a while when there were
only messages that Borland was better and that a dataview was a not good
functioning member of a dataset and the DataRowView.FindRows returns only a
datarowview, where it should be a position.
So please read first my first message before you write this kind of
sentences about my tone.
Where I know that your sentence is not bad intended, however it can be read
as that. When you had written "in a different style", I would not have
complained.
Just to make this clear.
Cor
"Nick Malik [Microsoft]" <ni*******@hotmail.nospam.com> schreef in bericht
news:NIOAd.305140$HA.192568@attbi_s01... Hello Relaxin,
apart from your last statement, which was a bit unfair, you are not wrong
in
your description of the object tree for a dataset. That said, datasets
are
part of a disconnected data retrieval model that is far more scalable than
the prior database tools. By the way, you bashed MS for the new
structure,
and referred to Borland, but MS created the older structure too. Seems
odd
to bring Borland into it at all.
Certainly, you can create "chatty" data interaction models that will do
the
exact same thing as "keyset". The rest of the retrieval types are
perfectly
available in ADO.NET, if you know how to use it. While I may take a
different tone that Cor, I would have to say that he has a point: there
is
very little useful functionality "lost" in ADO.NET.
From what I've heard, the product teams were getting a lot of heat because
the prior stuff had serious scalability problems. The responses were
something along the lines of "If the feature looks good, but leads to
serious problems later, why is it there? Remove it now and save us the
pain. We have to live with this stuff." MS was simply responding to the
express needs of their base. If the make a little money along the way...
good. That's called capitalism.
Back to technology.
If you have images in some of your columns, don't return those columns in
your dataset. Use a select statement or a stored proc to select only the
rows that you need for your non-image processing, and then when you need
an
image, ask for it from the database using a seperate statement. It's what
the older tools used to do for you, but at least this way, the code is
yours, so you are at more liberty to tweak it to get the performance you
need.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Relaxin" <me@yourhouse.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... I know EXACTLY what they are, but since you asked for it.
The DataSet contains 1 or more DataTables.
A DataTable contains 1 or more DataRows.
A DataRow contains 1 or more DataColumns.
A DataView is a subset and/or sorted view of the DataSet.
I'm still unsure what the purpose of the DataRowViews is, but I know
DataRowView.FindRows returns it.
Like I mentioned earlier, I have created my own components to handle
things the way they should be.
I'm mainly venting because I would have expected a better design from MS,
but I guess if you(most people in this NG, I assume) haven't seen
anything
other than MS, you wouldn't have anything to compare it to.
So of course you would think that this design is great.
Give Borland a try when you get a chance, you will see a hell of a
design.
You can tell that Borland tools are Developed By Developers for
Developers.
MS is designed for cash only!!
"Cor Ligthert" <no************@planet.nl> wrote in message
news:Oq**************@TK2MSFTNGP09.phx.gbl... > Relaxin,
>
> I get more and more the idea that you don't know what is a dataset,
> datatable, datarow, dataview and/or a datarowview in ADONET. Can you
> explain what they are in your opinion.
>
> Because when we talk about different things it is hard to make a
> discussion.
>
> Cor
>
Use a DataReader then - there's nothing to stop you from using the reaader
to store the info you need either in a dataset or collection of business
objects - however I'm not sure of the value of such an approach.
--
W.G. Ryan, MVP www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
"Relaxin" <me@yourhouse.com> wrote in message
news:e$**************@TK2MSFTNGP12.phx.gbl... What I need is a connected resultset within the confines of a DataSet.
My database is full of images, and as you could imagine, this is a painful
process when they are all loaded to the clientside.
Anyone with any knowledge in this area?
"J. Buelna - Houston, TX" <jbuelna-not@microsoft...yet.com> wrote in
message news:OT**************@TK2MSFTNGP11.phx.gbl...
"Relaxin" <me@yourhouse.com> wrote in message
news:eP**************@TK2MSFTNGP15.phx.gbl... It is just me or has MS created some of the worst ways to access and
display
data?
You can use a DataSet, but if you want to sort or filter the data to
must use a DataView which is created from a DataSet.
But, if you sort by using the Grid (clicking the header) you can no
longer
use the DataSet (or maybe the DataView, if that is what you are using)
to locate the record that the user has selected!!
You have to write code to get the current position...this should just
be a
property!!
Also, can someone explain to me why does the FindRows return
DataRowView...what can you do with a DataRowView, I haven't figure out
a way
to load this data into a new DataView or a DataSet (if there is a way,
please explain it to me). It seems that the FindRows should have just
return a new DataView!!
I understand why all of the necessary data access components are broken
out
into many different parts, but why not ALSO build a component that
encompasses all of the components and use that as an "enhanced DataSet"
that
can also be used as a Datasource to the grid and other components.(This
is
something that I have already done for myself.)
Maybe it's because I'm coming from Borland and expect top notch
development
tools/comopnents...where there VCL Framework and Data Access components
were
THE BEST!!!
But I had to leave Borland because their management said that they were
killing the Borland C++ Builder (BCB) product about 6 months ago. But,
they
just recently announced that they had a change of heart and will now
support
BCB.
That's a little to flaky for me, so I jumped ship and moved to MS.
But with what I have seen in VS.NET (C#), I might have to talk my
chances with Borland.
Hello Relaxin,
I'm sorry, I don't have time to go into details. Here are some
references:
Microsoft® ADO.NET Step by Step
http://www.microsoft.com/mspress/books/4825.asp
Microsoft® ADO.NET (Core Reference)
http://www.microsoft.com/mspress/books/5354.asp
Professional ADO.NET
http://www.amazon.com/exec/obidos/tg...books&n=507846
It would be good to learn and fully understand ADO.NET on an academic
level before trying to use it in a commercial project. Unless your
employer allows you to learn the as you go.
ADO.NET is not perfect, but there was a lot of thought that went into
architecting it and rest assured that there is a solution for most of
the problems you'll run into.
J. Buelna - Houston, TX
Relaxin - semantically you made a few goofs but you have the overall
concepts down and that's what's important.
The key thing that a DataRowView is used for in my experience is determining
state. Short of that - I don' think there's a whole lot of importance.
This is a technical distinction but let me make it anyway - when you are
looking at data, normally you only want to see one form of it - it's current
state. However if you needed to know what the previous state was - so you
could revert to it or show a confirm dialog - you may want to use it here.
--
W.G. Ryan, MVP www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
"Relaxin" <me@yourhouse.com> wrote in message
news:OW**************@TK2MSFTNGP15.phx.gbl... ok, 0 or more.
I guess you found the loophole you were looking for.
Have a great day!
"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl... Relaxin
I know EXACTLY what they are, but since you asked for it.
The DataSet contains 1 or more DataTables
references 0 or more
A DataTable contains 1 or more DataRows
references 0 or more.
A DataRow contains 1 or more DataColumns.
A DataRow references 0 or more Items described by the columncollection
from the DataTable
A DataView is a subset and/or sorted view of the DataSet.
The DataView is a view on a datatable not on the Dataset (as you
consequently state) which has filters and sort parameters in it. Every
DataTable contains one Dataview named DefaultView.
I'm still unsure what the purpose of the DataRowViews is, but I know
A DataRowView is a view on an single datarow however as well on other
class objects
DataRowView.FindRows returns it.
I don't know the DataRowView.FindRows method so I do not know what you
mean with this.
I don't think that your first statement about EXACTLY is very correct.
Just my thought,
Cor
>> A DataRowView is just like a DataRow - only for a view. If you need the underlying DataRow, just grab it from the .Row property of the
DataRowView - how easy is that?
That is exactly my point, why not just have FindRows return a DataView!!
Well, maybe because not everyone wants to use a DataView? Don't take
*YOUR* requirements and make them general - they might not be general
enough to be considered suitable for EVERYONE. Now there would
definitely be a possibility to at least provide an overloaded function
..FindRows that would return a DataView - then again, maybe MS decided
when they designed ADO.NET that this was too exotic an option.
After all, you really don't need to do much to get a DataView from
your results - just do it!
With the .NET dataset, it forces you to load all of the data to the
client...this doesn't work so well when you database is mainly made up of
images!
Well, then you might need to redesign your app - maybe you don't need
to select ALL the records INCLUDING the pictures! Maybe just rewrite
your app to select FEWER records, and leave the images in the DB,
until you REALLY need them.
Heck, it's not ALWAYS MS's fault when your system is designed badly!
;-)
Marc
================================================== ==============
Marc Scheuner May The Source Be With You!
Berne, Switzerland m.scheuner -at- inova.ch
Relaxin wrote: It is just me or has MS created some of the worst ways to access and
display data?
You can use a DataSet, but if you want to sort or filter the data to must
use a DataView which is created from a DataSet.
Here's what I ended up doing.
For more complex data tasks, instead of using a DataReader ( forward only,
no search ) or DataView ( no sort, no search ) when I need to manipulate
and change the data locally, I run a sql command as xml, and load it into
an XmlDocument.
It's disconnected.
It has latency.
And I can search ( and update it ) using XPath queries.
If I want to update the database with changes, no problem either.
XmlDocument does all the things that DataReader and DataSet don't do well.
--
"The Bush administration aims in its 2005 budget to cut by $1 billion the
$18 billion fund that helps about 2 million Americans--generally the poor,
elderly, and disabled--pay their rent."
-Mother Jones http://www.motherjones.com/news/dail...05/05_520.html
interesting.
Dataset can be easily converted to an XML document, and back to a Dataset
for update.
Sounds like you've made extra work for yourself.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Section 8" <ro***@moore.bond.007> wrote in message
news:xd***************@newsread3.news.pas.earthlin k.net... Relaxin wrote:
It is just me or has MS created some of the worst ways to access and
display data?
You can use a DataSet, but if you want to sort or filter the data to
must use a DataView which is created from a DataSet.
Here's what I ended up doing.
For more complex data tasks, instead of using a DataReader ( forward only,
no search ) or DataView ( no sort, no search ) when I need to manipulate
and change the data locally, I run a sql command as xml, and load it into
an XmlDocument.
It's disconnected.
It has latency.
And I can search ( and update it ) using XPath queries.
If I want to update the database with changes, no problem either.
XmlDocument does all the things that DataReader and DataSet don't do well.
--
"The Bush administration aims in its 2005 budget to cut by $1 billion the
$18 billion fund that helps about 2 million Americans--generally the poor,
elderly, and disabled--pay their rent."
-Mother Jones
http://www.motherjones.com/news/dail...05/05_520.html
Section 8,
To say this in a different tone, I want to say that you have to see the
dataset concept in its complete view. It is a part of System.Data where
derives from the classes Dataset DataTable DataColumn DataView
DataViewManager. This can in my opinion not be seen from one class alone as
the DataSet.
All of those classes have very strong methods and properties, while the only
thing which in my opinion are maybe still not strong enough are the public
events, however they are there and some very usefull.
To take the dataset again apart, one of the methods is the writeXML which is
a very overloaded method, (what most methods from system.data are). The
writeXML is not only usable to write to disk, however as it seems for me,
to endless streams and with that even easy to use.
Cor
> Well, then you might need to redesign your app - maybe you don't need to select ALL the records INCLUDING the pictures! Maybe just rewrite
your app to select FEWER records, and leave the images in the DB,
until you REALLY need them.
Heck, it's not ALWAYS MS's fault when your system is designed badly!
Just the answer I would expect from a MS junkie.
If I want to cache all the records to the client then MS should allow me
that option, if I need a live connection, that option should be a available
also.
Those were the options available to me with OLEDB.
MS shouldn't dictate to me how I should write my application, but should
give me the option to write it the way that "I" need it written.
Also remember, that just because you don't know my design doesn't mean its
bad, it just means you are a closed minded developer that thinks thier way
is the only way.
That's MS junkie thinking.
"Marc Scheuner [MVP ADSI]" <m.********@inova.SPAMBEGONE.ch> wrote in message
news:ce********************************@4ax.com... A DataRowView is just like a DataRow - only for a view. If you need
the underlying DataRow, just grab it from the .Row property of the
DataRowView - how easy is that?
That is exactly my point, why not just have FindRows return a DataView!!
Well, maybe because not everyone wants to use a DataView? Don't take
*YOUR* requirements and make them general - they might not be general
enough to be considered suitable for EVERYONE. Now there would
definitely be a possibility to at least provide an overloaded function
.FindRows that would return a DataView - then again, maybe MS decided
when they designed ADO.NET that this was too exotic an option.
After all, you really don't need to do much to get a DataView from
your results - just do it!
With the .NET dataset, it forces you to load all of the data to the
client...this doesn't work so well when you database is mainly made up of
images!
Well, then you might need to redesign your app - maybe you don't need
to select ALL the records INCLUDING the pictures! Maybe just rewrite
your app to select FEWER records, and leave the images in the DB,
until you REALLY need them.
Heck, it's not ALWAYS MS's fault when your system is designed badly!
;-)
Marc
================================================== ==============
Marc Scheuner May The Source Be With You!
Berne, Switzerland m.scheuner -at- inova.ch
"Relaxin" <me@yourhouse.com> wrote in message
news:eY**************@tk2msftngp13.phx.gbl... Well, then you might need to redesign your app - maybe you don't need
to select ALL the records INCLUDING the pictures! Maybe just rewrite
your app to select FEWER records, and leave the images in the DB,
until you REALLY need them.
Heck, it's not ALWAYS MS's fault when your system is designed badly!
Just the answer I would expect from a MS junkie.
While it is unclear if the recepient of that comment would consider it an
insult, it is clear to me that you intended to insult him. Let's keep a
cool head and discuss technology, OK?
If I want to cache all the records to the client then MS should allow me
that option,
why? If you are referring to server-side cursors, the option created
unscalable applications. It was only intended for very narrow uses, and was
nearly always misused by lazy developers creating apps that were not stress
tested before being inflicted on the general public. Those apps were so bad
that they gave MS technology a bad name, because they kept failing under
stress. Other database access methods don't allow this goofy design, and MS
probably shouldn't have either. Sometimes, when you release a technology,
it is hard to see how it will be used or misused. When you realize the
mistake, you take responsibility, correct it, and move on. The product
group did the right thing by turning the spotlight away from this idea.
if I need a live connection, that option should be a available
You have it. DataReader is a live connection. If by "live connection" you
are referring to rowsets, you have to realize that this was another wildly
misused "feature". It is rarely beneficial to use them and most apps that
used them did so at their own peril.
Those were the options available to me with OLEDB.
And you can still use OLEDB if you want. No one is stopping you. It works
just as well under .Net as it did under COM.
MS shouldn't dictate to me how I should write my application, but should
give me the option to write it the way that "I" need it written.
With power comes responsibility to know how to use it. While your tools
should provide power, they should also relieve the burden of learning. In
other words, they should lead you to make good decisions. The OLEDB tools
led to some decisions, not all of them were good. Apparently, you are
rather attached to some of your decisions, but that doesn't make them good
ones.
Also remember, that just because you don't know my design doesn't mean its
bad,
True. However, you have revealed quite a bit about your design in this
series of threads. From what you have revealed, a few very simple
modifications to your design would allow it to work more efficiently and
much more scalably. Is it wrong to point that out? I'm not defending the
previous poster for his emphasis (which was a bit condescending), but I do
agree that a NG is a place for open discussion, even if it means discussion
of design decisions on your part.
it just means you are a closed minded developer that thinks thier way
is the only way.
That's MS junkie thinking.
Don't be quick to throw stones, friend. In this discussion, who among us
has shown an unwillingness to admit when a design is using tools in a sloppy
manner to accomplish a goal that shows a strong lack of understanding of
efficient or effective data access. That unwillingness has led to much of
the frustration that is coming out.
Perhaps, if you listen carefully, you may hear the sound of people who want
to help you.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
Nick Malik [Microsoft] wrote: interesting.
Dataset can be easily converted to an XML document, and back to a Dataset
for update.
No, I mean to say, that's what I do.
But I do my manipulations and searching on XML using XPath, because
there are no equivalent methods with DataSet/DataReader.
Sounds like you've made extra work for yourself.
Hi Moe,
Are you also "Section 8"?
Because the original message from Section 8 said that he or she would run a
SQL query AS XML (my emphasis added).
There's a feature of SQL Server that uses the keywords 'AS XML' to direct
the server to return XML in the resultset. I thought that you were
referring to that.
If you are, in fact, using AS XML, then I wonder why not just use the
Dataset object, serialize to XML, manipulate it there as you see fit,
deserialize back to dataset and then use a data adapter to make the updates.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Moe Green" <mo*@green.vegas> wrote in message
news:33*************@individual.net... Nick Malik [Microsoft] wrote: interesting.
Dataset can be easily converted to an XML document, and back to a
Dataset for update.
No, I mean to say, that's what I do.
But I do my manipulations and searching on XML using XPath, because
there are no equivalent methods with DataSet/DataReader.
Sounds like you've made extra work for yourself.
Other database access methods don't allow this goofy design, and MS probably shouldn't have either.
I'm not sure what DB you are talking about, by the DB's Ive used, all have
that capability (except Firebird).
If you are referring to server-side cursors, the option created
unscalable applications.
My application scaled just fine for my needs and my customers love it.
Again, don't assume you know my application based off of how you design your
systems.
With power comes responsibility to know how to use it. While your tools
should provide power, they should also relieve the burden of learning.
Have you looked at C and C++, they have power but it made no effort in
relieving the burden of learning.
That's the way I like it, give me the power and it's up to me to learn it.
..NET has made some things easier, but it's has removed some of the power
that C++ developers want.
>Just the answer I would expect from a MS junkie.
I'm no MS junkie by any means - but I just think lots of developers
always insist that THEIR way is the only way to go, and MS better
support it - period.
Well, you gotta put yourself into MS' shoes, too, at times - they have
to design basic infrastructure code that will cover most needs of the
largest possible group of developers, and at the same time, everyone
expects MS to provide guidance in terms of best practices and so
forth. This isn't an easy place to be, either.
And yes, of course, MS could
a) design the system so that it will cover ALL imaginable scenarios -
when do you expect that to ship then??
b) make sure ANY vintage technology still works tens generations later
- welcome to messy APi's and stuff Those were the options available to me with OLEDB.
Yes - those were the days. The good old days when everything was
better.
Things change - in life, and especially in IT - get used to it, and
DEAL with it - or get out of this business.
MS shouldn't dictate to me how I should write my application, but should
give me the option to write it the way that "I" need it written.
Well, in that case - just stick to VB6 and OleDB then - no one FORCES
you to use ADO.NET by any means!
Also remember, that just because you don't know my design doesn't mean its
bad,
No - but just because your design USED to work (more or less) in OleDB
doesn't mean that it's good and suitable for today's way of doing
things, either! In the vast majority of cases, the fault or flaw
doesn't really exist in the "system" (like ADO.NET), but in the flawed
designs people try to coerce on top of the system (without
understanding the basics and workings of that system).
I just say "in general" - I don't know you, or your design - but I'm
just saying took a good look at it - most often you can fairly easily
make it a whole lot better, and get better results, rather than trying
to force your "old" design onto a new system not intended for that
kind of use.
Marc
================================================== ==============
Marc Scheuner May The Source Be With You!
Berne, Switzerland m.scheuner -at- inova.ch
Nick, I have to address one of your statements about "lazy developers"
misusing server side cursors. In VB6 DAO recordsets the default was client
side cursors, when ADO was introduced the default was server side cursors.
If you were testing in a small shop on a fast LAN the response time is barely
noticable. I think the problem is that the default in ADO should have been
client side cursors. This probaply lead to the scalability problems more
than programmer *laziness*.
I'm sure there were many programmers out there that did not notice the
difference until they rolled out into a different environment.
Cheers
"Nick Malik [Microsoft]" wrote: "Relaxin" <me@yourhouse.com> wrote in message
news:eY**************@tk2msftngp13.phx.gbl... Well, then you might need to redesign your app - maybe you don't need
to select ALL the records INCLUDING the pictures! Maybe just rewrite
your app to select FEWER records, and leave the images in the DB,
until you REALLY need them.
Heck, it's not ALWAYS MS's fault when your system is designed badly!
Just the answer I would expect from a MS junkie.
While it is unclear if the recepient of that comment would consider it an
insult, it is clear to me that you intended to insult him. Let's keep a
cool head and discuss technology, OK?
If I want to cache all the records to the client then MS should allow me
that option,
why? If you are referring to server-side cursors, the option created
unscalable applications. It was only intended for very narrow uses, and was
nearly always misused by lazy developers creating apps that were not stress
tested before being inflicted on the general public. Those apps were so bad
that they gave MS technology a bad name, because they kept failing under
stress. Other database access methods don't allow this goofy design, and MS
probably shouldn't have either. Sometimes, when you release a technology,
it is hard to see how it will be used or misused. When you realize the
mistake, you take responsibility, correct it, and move on. The product
group did the right thing by turning the spotlight away from this idea.
if I need a live connection, that option should be a available
You have it. DataReader is a live connection. If by "live connection" you
are referring to rowsets, you have to realize that this was another wildly
misused "feature". It is rarely beneficial to use them and most apps that
used them did so at their own peril.
Those were the options available to me with OLEDB.
And you can still use OLEDB if you want. No one is stopping you. It works
just as well under .Net as it did under COM.
MS shouldn't dictate to me how I should write my application, but should
give me the option to write it the way that "I" need it written.
With power comes responsibility to know how to use it. While your tools
should provide power, they should also relieve the burden of learning. In
other words, they should lead you to make good decisions. The OLEDB tools
led to some decisions, not all of them were good. Apparently, you are
rather attached to some of your decisions, but that doesn't make them good
ones.
Also remember, that just because you don't know my design doesn't mean its
bad,
True. However, you have revealed quite a bit about your design in this
series of threads. From what you have revealed, a few very simple
modifications to your design would allow it to work more efficiently and
much more scalably. Is it wrong to point that out? I'm not defending the
previous poster for his emphasis (which was a bit condescending), but I do
agree that a NG is a place for open discussion, even if it means discussion
of design decisions on your part.
it just means you are a closed minded developer that thinks thier way
is the only way.
That's MS junkie thinking.
Don't be quick to throw stones, friend. In this discussion, who among us
has shown an unwillingness to admit when a design is using tools in a sloppy
manner to accomplish a goal that shows a strong lack of understanding of
efficient or effective data access. That unwillingness has led to much of
the frustration that is coming out.
Perhaps, if you listen carefully, you may hear the sound of people who want
to help you.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
You are using the wrong class. You should be using a datareader if you need
a connected resultset. If you read the description of the class right out of
the documentation, it clearly states that datasets are disconnected. There
is no ambiguity here.
I am really impressed with the people in this newsgroup and the effort that
they are making to try to help you. However to be honest it doesn't seem
like you are here to get help... just to complain. I suggest that instead of
wasting everybodies time here, you should go and actually *READ* the
documentation and try to understand it, instead of using Intellisense to
write code.
"Relaxin" wrote: What I need is a connected resultset within the confines of a DataSet.
My database is full of images, and as you could imagine, this is a painful
process when they are all loaded to the clientside.
Anyone with any knowledge in this area?
"J. Buelna - Houston, TX" <jbuelna-not@microsoft...yet.com> wrote in message
news:OT**************@TK2MSFTNGP11.phx.gbl...
"Relaxin" <me@yourhouse.com> wrote in message
news:eP**************@TK2MSFTNGP15.phx.gbl... It is just me or has MS created some of the worst ways to access and
display
data?
You can use a DataSet, but if you want to sort or filter the data to must
use a DataView which is created from a DataSet.
But, if you sort by using the Grid (clicking the header) you can no
longer
use the DataSet (or maybe the DataView, if that is what you are using) to
locate the record that the user has selected!!
You have to write code to get the current position...this should just be
a
property!!
Also, can someone explain to me why does the FindRows return
DataRowView...what can you do with a DataRowView, I haven't figure out a
way
to load this data into a new DataView or a DataSet (if there is a way,
please explain it to me). It seems that the FindRows should have just
return a new DataView!!
I understand why all of the necessary data access components are broken
out
into many different parts, but why not ALSO build a component that
encompasses all of the components and use that as an "enhanced DataSet"
that
can also be used as a Datasource to the grid and other components.(This
is
something that I have already done for myself.)
Maybe it's because I'm coming from Borland and expect top notch
development
tools/comopnents...where there VCL Framework and Data Access components
were
THE BEST!!!
But I had to leave Borland because their management said that they were
killing the Borland C++ Builder (BCB) product about 6 months ago. But,
they
just recently announced that they had a change of heart and will now
support
BCB.
That's a little to flaky for me, so I jumped ship and moved to MS.
But with what I have seen in VS.NET (C#), I might have to talk my chances
with Borland.
Hello Relaxin,
I'm sorry, I don't have time to go into details. Here are some
references:
Microsoft® ADO.NET Step by Step
http://www.microsoft.com/mspress/books/4825.asp
Microsoft® ADO.NET (Core Reference)
http://www.microsoft.com/mspress/books/5354.asp
Professional ADO.NET
http://www.amazon.com/exec/obidos/tg...books&n=507846
It would be good to learn and fully understand ADO.NET on an academic
level before trying to use it in a commercial project. Unless your
employer allows you to learn the as you go.
ADO.NET is not perfect, but there was a lot of thought that went into
architecting it and rest assured that there is a solution for most of the
problems you'll run into.
J. Buelna - Houston, TX
you are right... it isn't necessarily the developer's fault. The tools
changed in a subtle way and that caused some problems.
I apologize for implying otherwise.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Doug Stoltz" <No****@myemail.com> wrote in message
news:66**********************************@microsof t.com... Nick, I have to address one of your statements about "lazy developers"
misusing server side cursors. In VB6 DAO recordsets the default was
client side cursors, when ADO was introduced the default was server side cursors.
If you were testing in a small shop on a fast LAN the response time is
barely noticable. I think the problem is that the default in ADO should have
been client side cursors. This probaply lead to the scalability problems more
than programmer *laziness*.
I'm sure there were many programmers out there that did not notice the
difference until they rolled out into a different environment.
Cheers
"Nick Malik [Microsoft]" wrote:
"Relaxin" <me@yourhouse.com> wrote in message
news:eY**************@tk2msftngp13.phx.gbl... > Well, then you might need to redesign your app - maybe you don't
need > to select ALL the records INCLUDING the pictures! Maybe just rewrite
> your app to select FEWER records, and leave the images in the DB,
> until you REALLY need them.
>
> Heck, it's not ALWAYS MS's fault when your system is designed badly!
Just the answer I would expect from a MS junkie.
While it is unclear if the recepient of that comment would consider it
an insult, it is clear to me that you intended to insult him. Let's keep a
cool head and discuss technology, OK?
If I want to cache all the records to the client then MS should allow
me that option,
why? If you are referring to server-side cursors, the option created
unscalable applications. It was only intended for very narrow uses, and
was nearly always misused by lazy developers creating apps that were not
stress tested before being inflicted on the general public. Those apps were so
bad that they gave MS technology a bad name, because they kept failing under
stress. Other database access methods don't allow this goofy design,
and MS probably shouldn't have either. Sometimes, when you release a
technology, it is hard to see how it will be used or misused. When you realize the
mistake, you take responsibility, correct it, and move on. The product
group did the right thing by turning the spotlight away from this idea.
if I need a live connection, that option should be a available
You have it. DataReader is a live connection. If by "live connection"
you are referring to rowsets, you have to realize that this was another
wildly misused "feature". It is rarely beneficial to use them and most apps
that used them did so at their own peril.
Those were the options available to me with OLEDB.
And you can still use OLEDB if you want. No one is stopping you. It
works just as well under .Net as it did under COM.
MS shouldn't dictate to me how I should write my application, but
should give me the option to write it the way that "I" need it written.
With power comes responsibility to know how to use it. While your tools
should provide power, they should also relieve the burden of learning.
In other words, they should lead you to make good decisions. The OLEDB
tools led to some decisions, not all of them were good. Apparently, you are
rather attached to some of your decisions, but that doesn't make them
good ones.
Also remember, that just because you don't know my design doesn't mean
its bad,
True. However, you have revealed quite a bit about your design in this
series of threads. From what you have revealed, a few very simple
modifications to your design would allow it to work more efficiently and
much more scalably. Is it wrong to point that out? I'm not defending
the previous poster for his emphasis (which was a bit condescending), but I
do agree that a NG is a place for open discussion, even if it means
discussion of design decisions on your part.
it just means you are a closed minded developer that thinks thier way
is the only way.
That's MS junkie thinking.
Don't be quick to throw stones, friend. In this discussion, who among
us has shown an unwillingness to admit when a design is using tools in a
sloppy manner to accomplish a goal that shows a strong lack of understanding of
efficient or effective data access. That unwillingness has led to much
of the frustration that is coming out.
Perhaps, if you listen carefully, you may hear the sound of people who
want to help you.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
The only problem with this statement is that, the "database" still provides
this functionality (keyset, dynamic, forwardonly, etc) and is available to
anyone NOT using .NET, they only removed it from the .NET language.
So Microsoft did not remove anything, they just didn't add it to .NET.
So my point would be...if using it in a certain way causes you problems,
then change it to something that is more suitable. You should be given
access to it if you need, it shouldn't have been left out of .NET just
because "some" developers were having problems. That was the beauty of
OLEDB, you had other options to choose from if the one you were using wasn't
working for you.
The way it stands now you have no options. "Nick Malik [Microsoft]" <ni*******@hotmail.nospam.com> wrote in message
news:NIOAd.305140$HA.192568@attbi_s01...
From what I've heard, the product teams were getting a lot of heat because
the prior stuff had serious scalability problems. The responses were
something along the lines of "If the feature looks good, but leads to
serious problems later, why is it there? Remove it now and save us the
pain. We have to live with this stuff." MS was simply responding to the
express needs of their base. If the make a little money along the way...
good. That's called capitalism.
If you would have read the entire thread, you would have seen that what I
need is a connected DataSet.
I need the power of the DataSet but in a connected manner, the way OLEDB
allowed.
So stop wasting my time.
"Darcy Townson" <Darcy To*****@discussions.microsoft.com> wrote in message
news:CF**********************************@microsof t.com... You are using the wrong class. You should be using a datareader if you
need
a connected resultset. If you read the description of the class right out
of
the documentation, it clearly states that datasets are disconnected.
There
is no ambiguity here.
I am really impressed with the people in this newsgroup and the effort
that
they are making to try to help you. However to be honest it doesn't seem
like you are here to get help... just to complain. I suggest that instead
of
wasting everybodies time here, you should go and actually *READ* the
documentation and try to understand it, instead of using Intellisense to
write code.
"Relaxin" wrote:
What I need is a connected resultset within the confines of a DataSet.
My database is full of images, and as you could imagine, this is a
painful
process when they are all loaded to the clientside.
Anyone with any knowledge in this area?
"J. Buelna - Houston, TX" <jbuelna-not@microsoft...yet.com> wrote in
message
news:OT**************@TK2MSFTNGP11.phx.gbl... >
> "Relaxin" <me@yourhouse.com> wrote in message
> news:eP**************@TK2MSFTNGP15.phx.gbl...
>> It is just me or has MS created some of the worst ways to access and
>> display
>> data?
>>
>> You can use a DataSet, but if you want to sort or filter the data to
>> must
>> use a DataView which is created from a DataSet.
>>
>> But, if you sort by using the Grid (clicking the header) you can no
>> longer
>> use the DataSet (or maybe the DataView, if that is what you are using)
>> to
>> locate the record that the user has selected!!
>>
>> You have to write code to get the current position...this should just
>> be
>> a
>> property!!
>>
>> Also, can someone explain to me why does the FindRows return
>> DataRowView...what can you do with a DataRowView, I haven't figure out
>> a
>> way
>> to load this data into a new DataView or a DataSet (if there is a way,
>> please explain it to me). It seems that the FindRows should have just
>> return a new DataView!!
>>
>> I understand why all of the necessary data access components are
>> broken
>> out
>> into many different parts, but why not ALSO build a component that
>> encompasses all of the components and use that as an "enhanced
>> DataSet"
>> that
>> can also be used as a Datasource to the grid and other
>> components.(This
>> is
>> something that I have already done for myself.)
>>
>> Maybe it's because I'm coming from Borland and expect top notch
>> development
>> tools/comopnents...where there VCL Framework and Data Access
>> components
>> were
>> THE BEST!!!
>>
>> But I had to leave Borland because their management said that they
>> were
>> killing the Borland C++ Builder (BCB) product about 6 months ago.
>> But,
>> they
>> just recently announced that they had a change of heart and will now
>> support
>> BCB.
>> That's a little to flaky for me, so I jumped ship and moved to MS.
>>
>> But with what I have seen in VS.NET (C#), I might have to talk my
>> chances
>> with Borland.
>>
>
>
> Hello Relaxin,
>
> I'm sorry, I don't have time to go into details. Here are some
> references:
>
> Microsoft® ADO.NET Step by Step
> http://www.microsoft.com/mspress/books/4825.asp
>
> Microsoft® ADO.NET (Core Reference)
> http://www.microsoft.com/mspress/books/5354.asp
>
> Professional ADO.NET
> http://www.amazon.com/exec/obidos/tg...books&n=507846
>
> It would be good to learn and fully understand ADO.NET on an academic
> level before trying to use it in a commercial project. Unless your
> employer allows you to learn the as you go.
>
> ADO.NET is not perfect, but there was a lot of thought that went into
> architecting it and rest assured that there is a solution for most of
> the
> problems you'll run into.
>
> J. Buelna - Houston, TX
>
Dude, chill. Its just that you are learning a totally new framework that
uses terms similar to VCL but aren't VCL objects. Once you get past that,
you can start to move forward learning the new framework.
Incidently, coming from a strong Delphi background, I can tell you that
Borland's solutions aren't nearly as flexible, but that the stock visual
controls all pretty much stink. Do what you did with borland, go find a
quality replacement.
And as for borland's 'quality' tools, I point you to dbExpress (fatally
flawed and a total 180 on previous db technologies they provided)
Give it a chance to learn the new dotNet framework without carrying forward
VCL expectations and it will go easier!
I didn't use dbExpress, I rolled my own.
But you must be on drugs to think that .NET tools are better than
Borland's!!
I have learned dotNet in the hope that it would be better or even on the
same level as Borland, but to my disappointment, it's much worst.
But since MS is changing the canvas, I believe I am forced to paint with
this delapitated brush known as dotNet.
I'm still hopeful that they will get it right, version 2.0 looks
interesting, but still lack some important features.
Such as proper/better handling of resources by the garbage collector.
"Xepol" <Xe***@discussions.microsoft.com> wrote in message
news:37**********************************@microsof t.com... Dude, chill. Its just that you are learning a totally new framework that
uses terms similar to VCL but aren't VCL objects. Once you get past that,
you can start to move forward learning the new framework.
Incidently, coming from a strong Delphi background, I can tell you that
Borland's solutions aren't nearly as flexible, but that the stock visual
controls all pretty much stink. Do what you did with borland, go find a
quality replacement.
And as for borland's 'quality' tools, I point you to dbExpress (fatally
flawed and a total 180 on previous db technologies they provided)
Give it a chance to learn the new dotNet framework without carrying
forward
VCL expectations and it will go easier!
"Relaxin" <me@yourhouse.com> wrote in message
news:er**************@TK2MSFTNGP14.phx.gbl... I have learned dotNet
bah.
J. Buelna - Houston, TX
IT'S NOT JUST YOU!
1.) The DataGrid is a piece of 5h1t. Once you sort it, all bets are off. And
if you want to highlight a row (or cell)... fuggedaboutit. It is much cheaper
to buy a grid that doesn't suck than to try to make the MS DataGrid do what
the old grid (as in VB6) used to do (out of the box).
2.) Is ADO.NET better or worse than OLEDB? I hated it at first (mostly
because I was using it with the DataGrid) but now I am used to it and it
works fine. Was it a pain in neck to learn? Sure... but if this job was easy,
anybody could do it and it wouldn't pay as much.
3.) Resistance is futile.
"Relaxin" wrote: It is just me or has MS created some of the worst ways to access and display
data?
You can use a DataSet, but if you want to sort or filter the data to must
use a DataView which is created from a DataSet.
But, if you sort by using the Grid (clicking the header) you can no longer
use the DataSet (or maybe the DataView, if that is what you are using) to
locate the record that the user has selected!!
You have to write code to get the current position...this should just be a
property!!
Also, can someone explain to me why does the FindRows return
DataRowView...what can you do with a DataRowView, I haven't figure out a way
to load this data into a new DataView or a DataSet (if there is a way,
please explain it to me). It seems that the FindRows should have just
return a new DataView!!
I understand why all of the necessary data access components are broken out
into many different parts, but why not ALSO build a component that
encompasses all of the components and use that as an "enhanced DataSet" that
can also be used as a Datasource to the grid and other components.(This is
something that I have already done for myself.)
Maybe it's because I'm coming from Borland and expect top notch development
tools/comopnents...where there VCL Framework and Data Access components were
THE BEST!!!
But I had to leave Borland because their management said that they were
killing the Borland C++ Builder (BCB) product about 6 months ago. But, they
just recently announced that they had a change of heart and will now support
BCB.
That's a little to flaky for me, so I jumped ship and moved to MS.
But with what I have seen in VS.NET (C#), I might have to talk my chances
with Borland.
Relaxin,
Man you just are not getting what ADO.NET is about are you. ADO.NET
first of all has nothing to do with the gatagrid, looks like your beef
lies with the winforms controls not ADO.NET. I myself am sometimes
frustrated with the datagrid control. The good news is that the
datagrid control has been completely revamped in the next revision of
the framework.
I work for a company which provides .NET training and a lot of people
have trouble transitioning from traditional programming concepts to .Net
concepts. Looks like you need a good understanding of what ADO.NET
provides and what it's role is in an application.
Forward only, keyset, etc have no place in datasets. How exactly would
you use a forward only dataset? A dataset is not a bound by a
connection to the db and does not behave like a recordset did in
previous programming frameworks.
I suggest you take the time to grasp what ADO.NET is before you make
suggestions on how it could be improved.
Sincerely,
Richard N.
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
All of what you said, I already know. Forward only, keyset, etc have no place in datasets. How exactly would
you use a forward only dataset?
I wouldn't use a forward only dataset, but I sure as heck would use a
keyset.
I suggest you take the time to grasp what ADO.NET is before you make
suggestions on how it could be improved.
I fully understand ADO.NET. I'm only griping about things that I need, that
it lacks.
If you could explain to me how to get what I'm looking for, then I would
could concede that I need to get a bit more understanding about ADO.NET
under my belt.
But if you can't, then don't assume that I don't know it...assume that I do
know it.
Thanks
"Richard" <no*******@borland.com> wrote in message
news:u7**************@TK2MSFTNGP15.phx.gbl... Relaxin,
Man you just are not getting what ADO.NET is about are you. ADO.NET
first of all has nothing to do with the gatagrid, looks like your beef
lies with the winforms controls not ADO.NET. I myself am sometimes
frustrated with the datagrid control. The good news is that the
datagrid control has been completely revamped in the next revision of
the framework.
I work for a company which provides .NET training and a lot of people
have trouble transitioning from traditional programming concepts to .Net
concepts. Looks like you need a good understanding of what ADO.NET
provides and what it's role is in an application.
Forward only, keyset, etc have no place in datasets. How exactly would
you use a forward only dataset? A dataset is not a bound by a
connection to the db and does not behave like a recordset did in
previous programming frameworks.
I suggest you take the time to grasp what ADO.NET is before you make
suggestions on how it could be improved.
Sincerely,
Richard N.
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
my two cents..
I stared out using ms vb and ms access and borland delphi. Been using
them since they were all created. So, I've seen quite a few changes. And
this has sometimes been painful.
I agree that you can't compare the objects in ADO.NET with previous
technologies. .Net changed a lot from DAO, ADO, and OLEDB. You can do
everything you used to - just a little differently, and sometimes a
little more work. I also wouldn't compare Borand and MS when it comes to
data access. I love Delphi and C++ builder but I haven't always been
thrilled with their options for data access, much less their
performance. But it was easy and powerful if used correctly.
All that being said..
I was quite upset when I discovered that the "OLD" functionality I was
used to was not incorporated within .NET, specifically the different
types of cursors and how they could be used. In my opinion it was not
necessary to completely remove these "options" from developers because
developers abused how they should be used. Microsoft could have created
a Recordset object as it was in the older versions within .NET and it
still would have value. To say that any object (DataSet, DataReader,
DataTable, etc) in .NET are the same as a Recordset isn't correct,
either. You can use the .NET objects to accomplish any of the old tasks
but they are not the same in their ease of use - you have to do a lot
more work to do some things.
Also, not every application has to scale. I've worked in environments
where I constantly put together small applications in VB or MS ACCESS
and I still used the old components (DAO, ADO) for these applications.
Why would I want a disconnected object from within MS ACCESS that's
going to reside on a client's pc and never go anywhere? For larger -
need to scale applications - ADO.NET is the best choice by far.
Wishing Microsoft would have giving me a Recordset I was famaliar with
does not make me a poor programmer. I don't like it when someone removes
a functionality either - And I know and use ADO.NET, VS.NET as well as
I've used other environments. I adapted. To me, having this
functionality in .NET would not have been a bad thing. But obviously, if
abused like before it could have casted a bad review for .NET. So, I
understand why it was not incorporated. But I don't have to like it. And
I can relate the original posters frustration with it. My only advice is
what most of the responders have offered. Learn ADO.NET as well as you
knew the other environments and make the best of it.
So, I wouldn't say that ADO.NET data access sucks. In all I think it
really is more versatile than pervious technologies. But that old
Recordset objects really rocks, even today when I need it. Too bad Def
Leopard can't say the same.
:-)
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Hi Darren,
You are right that a lot of things went downhill with the introduction
of .NET. I currently use JScript with ADO. I can write it in half the
time, with nothing more than a text editor and it runs on any windows
machine regardless of what "framework" is installed, with a few KB of
overhead instead of 65Mb, and fantastic speed. It works with everything
from XML, CSV, Acess JET, SQL Server etc.
I don't agree with you about DAO though, you should NOT use DAO - it sucks.
The main focus of .NET is so that beginners can drag "controls" onto
"forms" without understanding what's going on behind the scenes. If you
need to do some serious programming, leave the .NET at home:)
Darren Fuller wrote: my two cents..
I stared out using ms vb and ms access and borland delphi. Been using
them since they were all created. So, I've seen quite a few changes. And
this has sometimes been painful.
I agree that you can't compare the objects in ADO.NET with previous
technologies. .Net changed a lot from DAO, ADO, and OLEDB. You can do
everything you used to - just a little differently, and sometimes a
little more work. I also wouldn't compare Borand and MS when it comes to
data access. I love Delphi and C++ builder but I haven't always been
thrilled with their options for data access, much less their
performance. But it was easy and powerful if used correctly.
All that being said..
I was quite upset when I discovered that the "OLD" functionality I was
used to was not incorporated within .NET, specifically the different
types of cursors and how they could be used. In my opinion it was not
necessary to completely remove these "options" from developers because
developers abused how they should be used. Microsoft could have created
a Recordset object as it was in the older versions within .NET and it
still would have value. To say that any object (DataSet, DataReader,
DataTable, etc) in .NET are the same as a Recordset isn't correct,
either. You can use the .NET objects to accomplish any of the old tasks
but they are not the same in their ease of use - you have to do a lot
more work to do some things.
Also, not every application has to scale. I've worked in environments
where I constantly put together small applications in VB or MS ACCESS
and I still used the old components (DAO, ADO) for these applications.
Why would I want a disconnected object from within MS ACCESS that's
going to reside on a client's pc and never go anywhere? For larger -
need to scale applications - ADO.NET is the best choice by far.
Wishing Microsoft would have giving me a Recordset I was famaliar with
does not make me a poor programmer. I don't like it when someone removes
a functionality either - And I know and use ADO.NET, VS.NET as well as
I've used other environments. I adapted. To me, having this
functionality in .NET would not have been a bad thing. But obviously, if
abused like before it could have casted a bad review for .NET. So, I
understand why it was not incorporated. But I don't have to like it. And
I can relate the original posters frustration with it. My only advice is
what most of the responders have offered. Learn ADO.NET as well as you
knew the other environments and make the best of it.
So, I wouldn't say that ADO.NET data access sucks. In all I think it
really is more versatile than pervious technologies. But that old
Recordset objects really rocks, even today when I need it. Too bad Def
Leopard can't say the same.
:-)
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
--
Gerry Hickman (London UK)
I've learned .NET, took my C# certification test (and passed).
I now have a larger project that I must get done in a hurry. After much
thinking, I went to Borland's website and purchased C++ Builder 6.
I really tried to convince myself that I could do it faster in C#, but the
fact is, C++ Builder is a truly RAD development environment that doesn't
stop you from doing anything.
Hopefully one day I'll have a project that C# will fit, but if it needs to
be done in a hurry, I'll always fall back to C++ Builder.
"Gerry Hickman" <ge********@yahoo.co.uk> wrote in message
news:uK**************@TK2MSFTNGP14.phx.gbl... Hi Darren,
You are right that a lot of things went downhill with the introduction of
.NET. I currently use JScript with ADO. I can write it in half the time,
with nothing more than a text editor and it runs on any windows machine
regardless of what "framework" is installed, with a few KB of overhead
instead of 65Mb, and fantastic speed. It works with everything from XML,
CSV, Acess JET, SQL Server etc.
I don't agree with you about DAO though, you should NOT use DAO - it
sucks.
The main focus of .NET is so that beginners can drag "controls" onto
"forms" without understanding what's going on behind the scenes. If you
need to do some serious programming, leave the .NET at home:)
Darren Fuller wrote:
my two cents..
I stared out using ms vb and ms access and borland delphi. Been using
them since they were all created. So, I've seen quite a few changes. And
this has sometimes been painful.
I agree that you can't compare the objects in ADO.NET with previous
technologies. .Net changed a lot from DAO, ADO, and OLEDB. You can do
everything you used to - just a little differently, and sometimes a
little more work. I also wouldn't compare Borand and MS when it comes to
data access. I love Delphi and C++ builder but I haven't always been
thrilled with their options for data access, much less their
performance. But it was easy and powerful if used correctly.
All that being said..
I was quite upset when I discovered that the "OLD" functionality I was
used to was not incorporated within .NET, specifically the different
types of cursors and how they could be used. In my opinion it was not
necessary to completely remove these "options" from developers because
developers abused how they should be used. Microsoft could have created
a Recordset object as it was in the older versions within .NET and it
still would have value. To say that any object (DataSet, DataReader,
DataTable, etc) in .NET are the same as a Recordset isn't correct,
either. You can use the .NET objects to accomplish any of the old tasks
but they are not the same in their ease of use - you have to do a lot
more work to do some things. Also, not every application has to scale.
I've worked in environments
where I constantly put together small applications in VB or MS ACCESS
and I still used the old components (DAO, ADO) for these applications.
Why would I want a disconnected object from within MS ACCESS that's
going to reside on a client's pc and never go anywhere? For larger -
need to scale applications - ADO.NET is the best choice by far. Wishing
Microsoft would have giving me a Recordset I was famaliar with
does not make me a poor programmer. I don't like it when someone removes
a functionality either - And I know and use ADO.NET, VS.NET as well as
I've used other environments. I adapted. To me, having this
functionality in .NET would not have been a bad thing. But obviously, if
abused like before it could have casted a bad review for .NET. So, I
understand why it was not incorporated. But I don't have to like it. And
I can relate the original posters frustration with it. My only advice is
what most of the responders have offered. Learn ADO.NET as well as you
knew the other environments and make the best of it. So, I wouldn't say
that ADO.NET data access sucks. In all I think it
really is more versatile than pervious technologies. But that old
Recordset objects really rocks, even today when I need it. Too bad Def
Leopard can't say the same.
:-)
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
--
Gerry Hickman (London UK)
I agree with you Gerry. A lot has changed. Only time will tell where it
all goes. And I only use DAO in stand-alone Access applications -
because I can do it with my eyes closed. I know, I'm lazy. But with
those things the quicker the better. And all the ones I've done work
like a champ.
Relaxin, I agree with the RAD superiority with the Delphi/C++ Builder
environment. I've done a lot more with VB6 but nothing touches some of
the stuff I've done in Delphi. Delphi's probably not as powerful as C++
in some areas but it's always worked great for the stuff I've done. And
the third-party components are unbeatable. I've always wished if you
could morph the best parts of Delphi and VB you might come up with the
perfect environment. I like C++ Builder for C programming but I think
Borland cheesed on not porting the VCL from pascal to C. I redid a
couple of my Delphi apps in C++ Builder for grins and they ran a tad
slower than Delphi because of the fastcall/var swapping. But that could
have been my code. Either way it beats the hell out of MS Visual C++.
I've had people tell me they could build apps in MSVC++ as fast as
anything else but I've yet to see it. I know a couple guys that can come
close but Delphi is hard to beat in straight RAD development. But I'm
sure it's like anything. The more time you work in it the better ya get.
Nice debate. Take it easy.
Darren
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
"Relaxin" <me@yourhouse.com> wrote in message
news:eT**************@TK2MSFTNGP15.phx.gbl... I've learned .NET, took my C# certification test (and passed).
Congratulations.
I now have a larger project that I must get done in a hurry. After much
thinking, I went to Borland's website and purchased C++ Builder 6.
Probably a good idea, stick with what you know well if time constraints are
an issue.
I really tried to convince myself that I could do it faster in C#, but the
fact is, C++ Builder is a truly RAD development environment that doesn't
stop you from doing anything.
Sorry, what exactly does C# stop you from doing? I've used C# and C++
Builder and I found Builder to be MUCH less productive. Then again, I do
come from a VS background, so maybe that was it. Could it perhaps be that
you're just more used to Builder?
Hopefully one day I'll have a project that C# will fit, but if it needs to
be done in a hurry, I'll always fall back to C++ Builder.
I'm struggling to understand what kind of project C# doesn't fit? Are you
writing device drivers or something? If you don't fit a tool, that does not
imply that the tool doesn't fit a job.
"Gerry Hickman" <ge********@yahoo.co.uk> wrote in message
news:uK**************@TK2MSFTNGP14.phx.gbl... Hi Darren,
You are right that a lot of things went downhill with the introduction of
.NET. I currently use JScript with ADO. I can write it in half the time,
with nothing more than a text editor and it runs on any windows machine
regardless of what "framework" is installed, with a few KB of overhead
instead of 65Mb, and fantastic speed. It works with everything from XML,
CSV, Acess JET, SQL Server etc.
I don't agree with you about DAO though, you should NOT use DAO - it
sucks.
The main focus of .NET is so that beginners can drag "controls" onto
"forms" without understanding what's going on behind the scenes. If you
need to do some serious programming, leave the .NET at home:)
Darren Fuller wrote:
my two cents..
I stared out using ms vb and ms access and borland delphi. Been using
them since they were all created. So, I've seen quite a few changes. And
this has sometimes been painful.
I agree that you can't compare the objects in ADO.NET with previous
technologies. .Net changed a lot from DAO, ADO, and OLEDB. You can do
everything you used to - just a little differently, and sometimes a
little more work. I also wouldn't compare Borand and MS when it comes to
data access. I love Delphi and C++ builder but I haven't always been
thrilled with their options for data access, much less their
performance. But it was easy and powerful if used correctly.
All that being said..
I was quite upset when I discovered that the "OLD" functionality I was
used to was not incorporated within .NET, specifically the different
types of cursors and how they could be used. In my opinion it was not
necessary to completely remove these "options" from developers because
developers abused how they should be used. Microsoft could have created
a Recordset object as it was in the older versions within .NET and it
still would have value. To say that any object (DataSet, DataReader,
DataTable, etc) in .NET are the same as a Recordset isn't correct,
either. You can use the .NET objects to accomplish any of the old tasks
but they are not the same in their ease of use - you have to do a lot
more work to do some things. Also, not every application has to scale.
I've worked in environments
where I constantly put together small applications in VB or MS ACCESS
and I still used the old components (DAO, ADO) for these applications.
Why would I want a disconnected object from within MS ACCESS that's
going to reside on a client's pc and never go anywhere? For larger -
need to scale applications - ADO.NET is the best choice by far. Wishing
Microsoft would have giving me a Recordset I was famaliar with
does not make me a poor programmer. I don't like it when someone removes
a functionality either - And I know and use ADO.NET, VS.NET as well as
I've used other environments. I adapted. To me, having this
functionality in .NET would not have been a bad thing. But obviously, if
abused like before it could have casted a bad review for .NET. So, I
understand why it was not incorporated. But I don't have to like it. And
I can relate the original posters frustration with it. My only advice is
what most of the responders have offered. Learn ADO.NET as well as you
knew the other environments and make the best of it. So, I wouldn't say
that ADO.NET data access sucks. In all I think it
really is more versatile than pervious technologies. But that old
Recordset objects really rocks, even today when I need it. Too bad Def
Leopard can't say the same.
:-)
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
--
Gerry Hickman (London UK)
"Sean Hederman" <us***@blogentry.com> wrote in message
news:d0**********@ctb-nnrp2.saix.net... I now have a larger project that I must get done in a hurry. After much
thinking, I went to Borland's website and purchased C++ Builder 6.
Probably a good idea, stick with what you know well if time constraints
are an issue.
I really tried to convince myself that I could do it faster in C#, but
the fact is, C++ Builder is a truly RAD development environment that
doesn't stop you from doing anything.
I'm struggling to understand what kind of project C# doesn't fit? Are you writing device drivers or something? If you don't fit a tool, that does
not imply that the tool doesn't fit a job.>
The Job that "I" have found that C# don't fit is when you need to load a lot
of data and 80% of it is varies pictures.
I wish C#'s dataset had the ability to keep data at the server side instead
of loading it all to the client.
Plus with .NET non-determisitic garbage collector, the client would running
out of memory or the system would become very sluggish.
Also, the inability to seperate your business logic from your interface.
The inability to change the key in the Keypress event.
The disassociation of your dataset from what the user is doing to it through
the components (mainly the grid).
And a semi-clunky IDE, although, there some things in the IDE that are
better than Borland's.
Also, in C# (.NET 2.0), why do you need to select the class name refactoring
meun option. The IDE already knows the name of the class, how about just
automatically "refactoring" when I change the name...oh, and how about
changing the name of the events (automatically) also.
The product is just to immature.
I just felt I would spend more time fighting and working around issues,
rather than writing code.
Don't get me wrong, there is plenty to like about C#, it just needs to
polished up.
"Relaxin" <me@yourhouse.com> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...
"Sean Hederman" <us***@blogentry.com> wrote in message
news:d0**********@ctb-nnrp2.saix.net...
I now have a larger project that I must get done in a hurry. After much
thinking, I went to Borland's website and purchased C++ Builder 6.
Probably a good idea, stick with what you know well if time constraints
are an issue.
I really tried to convince myself that I could do it faster in C#, but
the fact is, C++ Builder is a truly RAD development environment that
doesn't stop you from doing anything.
I'm struggling to understand what kind of project C# doesn't fit? Are you writing device drivers or something? If you don't fit a tool, that does
not imply that the tool doesn't fit a job.>
The Job that "I" have found that C# don't fit is when you need to load a
lot of data and 80% of it is varies pictures.
Have a look at
http://www.windowsforms.net/Applicat...=50&tabindex=8
It's a .NET app that serves photos up to Windows Forms, Web Forms and CE
clients.
I wish C#'s dataset had the ability to keep data at the server side
instead of loading it all to the client.
Since a Dataset is a client-side disconnected data source this would
completely be against it's design. If you want to iterate through back-end
data with more fine-grained control, use the IDataReader implementations.
Plus with .NET non-determisitic garbage collector, the client would
running out of memory or the system would become very sluggish.
Actually, it doesn't matter what system you were running, pulling back a
databases worth of images into memory will result in the same symptoms.
Also, the inability to seperate your business logic from your interface
I'm not sure what you're trying to get at here. If you're trying to say that
..NET doesn't support n-tier architectures, you're very, very wrong. If
you're trying to talk about the control of the actual UI being separated
from the forms code itself, have a look at the Command pattern and
http://msdn.microsoft.com/library/de...html/uipab.asp
The inability to change the key in the Keypress event.
Events are not meant to be two-way data transfer mechanisms. About the only
time events allow parameters to be passed back is when the event arguments
support a Handled property. If you want to manipulate the text based on what
key was pressed you can just do that. Another option would be to use the
SendKeys class after setting e.Handled = true.
The disassociation of your dataset from what the user is doing to it
through the components (mainly the grid).
Dataset.Clone()
And a semi-clunky IDE, although, there some things in the IDE that are
better than Borland's.
Matter of taste I suppose. I personally find Borlands IDE horribly clunky.
Also, in C# (.NET 2.0), why do you need to select the class name
refactoring meun option. The IDE already knows the name of the class, how
about just automatically "refactoring" when I change the name
Dunno about you, but I don't like the IDE doing stuff without my knowledge.
What if I want to change the class name without anything else changing?
...oh, and how about changing the name of the events (automatically) also.
Doesn't really apply to me, since I don't use the default event names
anyway.
The product is just to immature.
Not for me, not for my team, not for my company. We find it an absolute
dream.
I just felt I would spend more time fighting and working around issues,
rather than writing code.
Exactly why I like .NET ;D
Isn't taste a strange thing?
Don't get me wrong, there is plenty to like about C#, it just needs to
polished up.
"Sean Hederman" <us***@blogentry.com> wrote in message
news:d1**********@ctb-nnrp2.saix.net... "Relaxin" <me@yourhouse.com> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...
The Job that "I" have found that C# don't fit is when you need to load a
lot of data and 80% of it is varies pictures.
Have a look at
http://www.windowsforms.net/Applicat...=50&tabindex=8
It's a .NET app that serves photos up to Windows Forms, Web Forms and CE
clients.
I wish C#'s dataset had the ability to keep data at the server side
instead of loading it all to the client.
Since a Dataset is a client-side disconnected data source this would
completely be against it's design. If you want to iterate through back-end
data with more fine-grained control, use the IDataReader implementations.
But, ADO supported server-side connections and I need it databound to a
grid.
So, the DataReader won't help. Plus with .NET non-determisitic garbage collector, the client would
running out of memory or the system would become very sluggish.
Actually, it doesn't matter what system you were running, pulling back a
databases worth of images into memory will result in the same symptoms.
Not if most of it is keep on the server instead of the client. Also, the inability to seperate your business logic from your interface
I'm not sure what you're trying to get at here. If you're trying to say
that .NET doesn't support n-tier architectures, you're very, very wrong.
If you're trying to talk about the control of the actual UI being
separated from the forms code itself, have a look at the Command pattern
and
http://msdn.microsoft.com/library/de...html/uipab.asp
I'm not talking about n-tier, I mean not having to place you business logic
directly underneath your UI controls.
Borland handles this by means of a datamodule...which is where you place
your business logic and totally seperated from your interface. The inability to change the key in the Keypress event.
Events are not meant to be two-way data transfer mechanisms. About the
only time events allow parameters to be passed back is when the event
arguments support a Handled property. If you want to manipulate the text
based on what key was pressed you can just do that. Another option would
be to use the SendKeys class after setting e.Handled = true.
Borland allowed it, so you can't say it's not meant to be. It's just a poor
implementation on MS part. The disassociation of your dataset from what the user is doing to it
through the components (mainly the grid).
Dataset.Clone()
???... This just make a skeleton of your dataset without the data, now you
are also disassociated from your data. And a semi-clunky IDE, although, there some things in the IDE that are
better than Borland's.
Matter of taste I suppose. I personally find Borlands IDE horribly clunky.
Also, in C# (.NET 2.0), why do you need to select the class name
refactoring meun option. The IDE already knows the name of the class,
how about just automatically "refactoring" when I change the name
Dunno about you, but I don't like the IDE doing stuff without my
knowledge. What if I want to change the class name without anything else
changing?
We are talking about changing the class name...you have to change it
everywhere if you want it to compile.
Are you just making up stuff to try to support MS decisions? ...oh, and how about changing the name of the events (automatically)
also.
Doesn't really apply to me, since I don't use the default event names
anyway.
The product is just to immature.
Not for me, not for my team, not for my company. We find it an absolute
dream.
I just felt I would spend more time fighting and working around issues,
rather than writing code.
Exactly why I like .NET ;D
Isn't taste a strange thing?
Again, I think you are just making up arguments to support your decision.
I want .NET to succeed, I don't want to go back to Borland (for business
reasons), but I feel that currently I have no choice.
"Relaxin" <me@yourhouse.com> wrote in message
news:eK**************@tk2msftngp13.phx.gbl...
"Sean Hederman" <us***@blogentry.com> wrote in message
news:d1**********@ctb-nnrp2.saix.net... "Relaxin" <me@yourhouse.com> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...
The Job that "I" have found that C# don't fit is when you need to load a
lot of data and 80% of it is varies pictures.
Have a look at
http://www.windowsforms.net/Applicat...=50&tabindex=8
It's a .NET app that serves photos up to Windows Forms, Web Forms and CE
clients.
I wish C#'s dataset had the ability to keep data at the server side
instead of loading it all to the client.
Since a Dataset is a client-side disconnected data source this would
completely be against it's design. If you want to iterate through
back-end data with more fine-grained control, use the IDataReader
implementations.
But, ADO supported server-side connections and I need it databound to a
grid.
So, the DataReader won't help.
It looks like in this scenario you would have to use manual binding.
Needless to say Dataset (being disconnected) cannot support server-side
cursors. Plus with .NET non-determisitic garbage collector, the client would
running out of memory or the system would become very sluggish.
Actually, it doesn't matter what system you were running, pulling back a
databases worth of images into memory will result in the same symptoms.
Not if most of it is keep on the server instead of the client.
Also, the inability to seperate your business logic from your interface
I'm not sure what you're trying to get at here. If you're trying to say
that .NET doesn't support n-tier architectures, you're very, very wrong.
If you're trying to talk about the control of the actual UI being
separated from the forms code itself, have a look at the Command pattern
and
http://msdn.microsoft.com/library/de...html/uipab.asp
I'm not talking about n-tier, I mean not having to place you business
logic directly underneath your UI controls.
Borland handles this by means of a datamodule...which is where you place
your business logic and totally seperated from your interface.
Again, I don't place my business logic directly under my controls. It is in
a separate tier completely separated from my interface. The interface is
little more than simple commands executing components of the business logic
& presentation logic. The inability to change the key in the Keypress event.
Events are not meant to be two-way data transfer mechanisms. About the
only time events allow parameters to be passed back is when the event
arguments support a Handled property. If you want to manipulate the text
based on what key was pressed you can just do that. Another option would
be to use the SendKeys class after setting e.Handled = true.
Borland allowed it, so you can't say it's not meant to be. It's just a
poor implementation on MS part.
..NET is different from the Borland libraries and has different design
guidelines and principles. Under the .NET design principles it doesn't make
sense to have events modifying data, Borland seemed to think that was OK.
Now, given a multicast event to KeyPress, if the one event sink indicates
that the key event should be cancelled, another indicates that it should be
changed to 'A' and another indicates that instead it should be 'B', what is
your control supposed to do?
In .NET this cannot happen because the only input the event sinks have is
whether the key event should be cancelled or not, and that's a simple
boolean OR. Now, it's your prerogative to say that this is poor
implementation, but I personally feel that an implementation which allowed a
scenario like I just described would be a poor implementation. The disassociation of your dataset from what the user is doing to it
through the components (mainly the grid).
Dataset.Clone()
???... This just make a skeleton of your dataset without the data, now you
are also disassociated from your data.
Sorry, Dataset.Copy(), my mistake. One thing you don't seem to be grokking
is that with Dataset you're ALWAYS disconnected from your data. And a semi-clunky IDE, although, there some things in the IDE that are
better than Borland's.
Matter of taste I suppose. I personally find Borlands IDE horribly
clunky.
Also, in C# (.NET 2.0), why do you need to select the class name
refactoring meun option. The IDE already knows the name of the class,
how about just automatically "refactoring" when I change the name
Dunno about you, but I don't like the IDE doing stuff without my
knowledge. What if I want to change the class name without anything else
changing?
We are talking about changing the class name...you have to change it
everywhere if you want it to compile.
Are you just making up stuff to try to support MS decisions?
No, I just don't like tools doing things automatically without me knowing
about it. At the very least I'd like some sort of popup, to allow me to
agree or disagree, but that could be very annoying. I like my changes to my
code to be based on conscious decisions on my part, rather than on some tool
trying to "help" me when I may or may not need help. If I want help
refactoring, I ask my tool for it. ...oh, and how about changing the name of the events (automatically)
also.
Doesn't really apply to me, since I don't use the default event names
anyway.
The product is just to immature.
Not for me, not for my team, not for my company. We find it an absolute
dream.
I just felt I would spend more time fighting and working around issues,
rather than writing code.
Exactly why I like .NET ;D
Isn't taste a strange thing?
Again, I think you are just making up arguments to support your decision.
I want .NET to succeed, I don't want to go back to Borland (for business
reasons), but I feel that currently I have no choice.
Arguments? I'm not making up arguments. I'm trying to get across to you that
not everyone feels that the Borland tools are better than .NET, and trying
to indicate that a major reason why might be taste. So basically my point is
that it is my *opinion* that .NET is fine for what I do, and it is your
*opinion* that Borland is better suited. You don't like the fact that .NET
does not do things the Borland(TM) way, and that's fine, if you prefer the
Borland way by all means use it.
Just don't come along and make trashy comments without being able to back
them up with a little more than "Borland does it...so it's just poor MS
implementation". This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Grant Stanley |
last post by:
I'm developing an application in VS.Net 2003 using C#, which uses Crystal
Reports.
When creating each report, crystal asks where the database to use is, so I
specify our SQL server using the ADO...
|
by: Relaxin |
last post by:
It is just me or has MS created some of the worst ways to access and display
data?
You can use a DataSet, but if you want to sort or filter the data to must
use a DataView which is created from...
|
by: windandwaves |
last post by:
Hi Folk
I have been asked to create an e-commerce website, where we need to
connect to an SQL database. The database is used to run their POS in
several branches. As this database is on the...
|
by: ljh |
last post by:
Why would you choose SQL Express (which requires an installed application to
work) over the simplicity of an Access database which has no dependencies?
|
by: pereges |
last post by:
Hello, I'm trying to build a database driven website for a library
management system. The database is stored on a remote server which all
of my team mates can access. I've installed MySQL, PHP and...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
