| Groups | Blog | Home |
dotnet general : Database access sucks!
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.
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 [quoted text, click to view] "Relaxin" <me@yourhouse.com> wrote in message news:eP8eDTW7EHA.4028@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 [quoted text, click to view] "Relaxin" <me@yourhouse.com> wrote in message news:eP8eDTW7EHA.4028@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. > > >
[quoted text, click to view] >----- Original Message ----- >From: "Marc Scheuner [MVP ADSI]" <m.scheuner@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!! [quoted text, click to view] > I really think you ought to put a bit more brain power into learning I have and I've used the best. I also used and created components from > 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! > 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.scheuner@inova.SPAMBEGONE.ch> Newsgroups: microsoft.public.dotnet.general Sent: Tuesday, December 28, 2004 11:00 PM Subject: Re: Database access sucks! [quoted text, click to view] > >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
[quoted text, click to view] > 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. [quoted text, click to view] > 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! [quoted text, click to view] > 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. [quoted text, click to view] "Cor Ligthert" <notmyfirstname@planet.nl> wrote in message news:OcadZzY7EHA.1396@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 > >
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!! [quoted text, click to view] "Cor Ligthert" <notmyfirstname@planet.nl> wrote in message news:OqAvBUZ7EHA.3416@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 >
[quoted text, click to view]
>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! [quoted text, click to view] >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? [quoted text, click to view] >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!
[quoted text, click to view] "Relaxin" <me@yourhouse.com> wrote in message news:eP8eDTW7EHA.4028@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/detail/-/186100527X/qid=1104333519/sr=8-3/ref=pd_csp_3/102-3805879-7946505?v=glance&s=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
Marc,
[quoted text, click to view] > Why you wrote that. (I first did want you to give an answer and than answer > It's just you! :-) Hey, you almost *ASKED* for that! ;-) > that again with). "It was only that I could not now". :-) Cor
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? [quoted text, click to view] "J. Buelna - Houston, TX" <jbuelna-not@microsoft...yet.com> wrote in message news:OT$wqrb7EHA.3336@TK2MSFTNGP11.phx.gbl... > > "Relaxin" <me@yourhouse.com> wrote in message > news:eP8eDTW7EHA.4028@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/detail/-/186100527X/qid=1104333519/sr=8-3/ref=pd_csp_3/102-3805879-7946505?v=glance&s=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! [quoted text, click to view] "Cor Ligthert" <notmyfirstname@planet.nl> wrote in message news:%23Lk24Zb7EHA.3708@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 >
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
Relaxin
[quoted text, click to view] >I know EXACTLY what they are, but since you asked for it. references 0 or more> The DataSet contains 1 or more DataTables [quoted text, click to view] > A DataTable contains 1 or more DataRows references 0 or more.[quoted text, click to view] > A DataRow contains 1 or more DataColumns. A DataRow references 0 or more Items described by the columncollection from the DataTable [quoted text, click to view] > 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. [quoted text, click to view] > 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 [quoted text, click to view] > 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
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 [quoted text, click to view] 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. > >
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. -- [quoted text, click to view] "Relaxin" <me@yourhouse.com> wrote in message news:%23xPrW0a7EHA.2180@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" <notmyfirstname@planet.nl> wrote in message > news:OqAvBUZ7EHA.3416@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]" <nickmalik@hotmail.nospam.com> schreef in bericht news:NIOAd.305140$HA.192568@attbi_s01... [quoted text, click to view] > 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:%23xPrW0a7EHA.2180@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" <notmyfirstname@planet.nl> wrote in message >> news:OqAvBUZ7EHA.3416@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 [quoted text, click to view] "Relaxin" <me@yourhouse.com> wrote in message news:e$x4jSd7EHA.1264@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$wqrb7EHA.3336@TK2MSFTNGP11.phx.gbl... > > > > "Relaxin" <me@yourhouse.com> wrote in message > > news:eP8eDTW7EHA.4028@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/detail/-/186100527X/qid=1104333519/sr=8-3/ref=pd_csp_3/102-3805879-7946505?v=glance&s=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 [quoted text, click to view] "Relaxin" <me@yourhouse.com> wrote in message news:OWddYTd7EHA.2316@TK2MSFTNGP15.phx.gbl... > ok, 0 or more. > I guess you found the loophole you were looking for. > > Have a great day! > > "Cor Ligthert" <notmyfirstname@planet.nl> wrote in message > news:%23Lk24Zb7EHA.3708@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 > > > >
[quoted text, click to view]
> 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. [quoted text, click to view] "Marc Scheuner [MVP ADSI]" <m.scheuner@inova.SPAMBEGONE.ch> wrote in message news:ce1it0dis2btl017fjs95afbjppk6oqi9e@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
[quoted text, click to view]
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/dailymojo/2004/05/05_520.html
[quoted text, click to view]
>> 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! [quoted text, click to view] >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!
[quoted text, click to view]
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. [quoted text, click to view] >
> Sounds like you've made extra work for yourself.
Other database access methods don't allow this goofy design, and MS
[quoted text, click to view] > 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). [quoted text, click to view] > If you are referring to server-side cursors, the option created My application scaled just fine for my needs and my customers love it. > unscalable applications. Again, don't assume you know my application based off of how you design your systems. [quoted text, click to view] >With power comes responsibility to know how to use it. While your tools Have you looked at C and C++, they have power but it made no effort in > should provide power, they should also relieve the burden of learning. 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.
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. -- [quoted text, click to view] "Section 8" <roger@moore.bond.007> wrote in message news:xd8Cd.5682$Cc.738@newsread3.news.pas.earthlink.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/dailymojo/2004/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
[quoted text, click to view]
"Relaxin" <me@yourhouse.com> wrote in message news:eY797Sb8EHA.2032@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? [quoted text, click to view] > 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. [quoted text, click to view] > 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. [quoted text, click to view] > 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. [quoted text, click to view] > > 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. [quoted text, click to view] > > 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. [quoted text, click to view] > 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. --
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. -- [quoted text, click to view] "Moe Green" <moe@green.vegas> wrote in message news:33tklpF43c66vU1@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. > >
[quoted text, click to view]
>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 [quoted text, click to view] >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. [quoted text, click to view] >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! [quoted text, click to view] >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!
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 [quoted text, click to view] "Nick Malik [Microsoft]" wrote:
> "Relaxin" <me@yourhouse.com> wrote in message > news:eY797Sb8EHA.2032@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. [quoted text, click to view] "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$wqrb7EHA.3336@TK2MSFTNGP11.phx.gbl... > > > > "Relaxin" <me@yourhouse.com> wrote in message > > news:eP8eDTW7EHA.4028@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/detail/-/186100527X/qid=1104333519/sr=8-3/ref=pd_csp_3/102-3805879-7946505?v=glance&s=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 > > > >
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. [quoted text, click to view] "Darcy Townson" <Darcy Townson@discussions.microsoft.com> wrote in message news:CFFF6C14-4482-4BA9-B666-1A5BFEAC78C6@microsoft.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$wqrb7EHA.3336@TK2MSFTNGP11.phx.gbl... >> > >> > "Relaxin" <me@yourhouse.com> wrote in message >> > news:eP8eDTW7EHA.4028@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/detail/-/186100527X/qid=1104333519/sr=8-3/ref=pd_csp_3/102-3805879-7946505?v=glance&s=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. -- [quoted text, click to view] "Doug Stoltz" <NoSpam@myemail.com> wrote in message news:66991638-F272-413A-8D38-533FE765AFE5@microsoft.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:eY797Sb8EHA.2032@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. [quoted text, click to view] >"Nick Malik [Microsoft]" <nickmalik@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.
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
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. [quoted text, click to view] "Xepol" <Xepol@discussions.microsoft.com> wrote in message news:37FE3AA9-1038-4B63-AA3B-9013A5168C23@microsoft.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!
|