Database access sucks!

[Darcy Townson]

Re: Database access sucks!

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:
[color=blue]
> 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$wqrb7EH A.3336@TK2MSFTN GP11.phx.gbl...[color=green]
> >
> > "Relaxin" <me@yourhouse.c om> wrote in message
> > news:eP8eDTW7EH A.4028@TK2MSFTN GP15.phx.gbl...[color=darkred]
> >> 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...w hat 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.(Thi s
> >> 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...wh ere 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.
> >>[/color]
> >
> >
> > 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
> >[/color]
>
>
>[/color]

[Nick Malik [Microsoft]]

Re: Database access sucks!

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" <NoSpam@myemail .com> wrote in message
news:66991638-F272-413A-8D38-533FE765AFE5@mi crosoft.com...[color=blue]
> Nick, I have to address one of your statements about "lazy developers"
> misusing server side cursors. In VB6 DAO recordsets the default was[/color]
client[color=blue]
> 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[/color]
barely[color=blue]
> noticable. I think the problem is that the default in ADO should have[/color]
been[color=blue]
> 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:
>[color=green]
> > "Relaxin" <me@yourhouse.c om> wrote in message
> > news:eY797Sb8EH A.2032@tk2msftn gp13.phx.gbl...[color=darkred]
> > > > Well, then you might need to redesign your app - maybe you don't[/color][/color][/color]
need[color=blue][color=green][color=darkred]
> > > > 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.
> > >[/color]
> >
> > While it is unclear if the recepient of that comment would consider it[/color][/color]
an[color=blue][color=green]
> > insult, it is clear to me that you intended to insult him. Let's keep a
> > cool head and discuss technology, OK?
> >
> >[color=darkred]
> > > If I want to cache all the records to the client then MS should allow[/color][/color][/color]
me[color=blue][color=green][color=darkred]
> > > that option,[/color]
> >
> > why? If you are referring to server-side cursors, the option created
> > unscalable applications. It was only intended for very narrow uses, and[/color][/color]
was[color=blue][color=green]
> > nearly always misused by lazy developers creating apps that were not[/color][/color]
stress[color=blue][color=green]
> > tested before being inflicted on the general public. Those apps were so[/color][/color]
bad[color=blue][color=green]
> > that they gave MS technology a bad name, because they kept failing under
> > stress. Other database access methods don't allow this goofy design,[/color][/color]
and MS[color=blue][color=green]
> > probably shouldn't have either. Sometimes, when you release a[/color][/color]
technology,[color=blue][color=green]
> > 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.
> >[color=darkred]
> > > if I need a live connection, that option should be a available[/color]
> >
> > You have it. DataReader is a live connection. If by "live connection"[/color][/color]
you[color=blue][color=green]
> > are referring to rowsets, you have to realize that this was another[/color][/color]
wildly[color=blue][color=green]
> > misused "feature". It is rarely beneficial to use them and most apps[/color][/color]
that[color=blue][color=green]
> > used them did so at their own peril.
> >[color=darkred]
> > > Those were the options available to me with OLEDB.[/color]
> >
> > And you can still use OLEDB if you want. No one is stopping you. It[/color][/color]
works[color=blue][color=green]
> > just as well under .Net as it did under COM.
> >[color=darkred]
> > >
> > > MS shouldn't dictate to me how I should write my application, but[/color][/color][/color]
should[color=blue][color=green][color=darkred]
> > > give me the option to write it the way that "I" need it written.[/color]
> >
> > With power comes responsibility to know how to use it. While your tools
> > should provide power, they should also relieve the burden of learning.[/color][/color]
In[color=blue][color=green]
> > other words, they should lead you to make good decisions. The OLEDB[/color][/color]
tools[color=blue][color=green]
> > 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[/color][/color]
good[color=blue][color=green]
> > ones.
> >[color=darkred]
> > >
> > > Also remember, that just because you don't know my design doesn't mean[/color][/color][/color]
its[color=blue][color=green][color=darkred]
> > > bad,[/color]
> >
> > 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[/color][/color]
the[color=blue][color=green]
> > previous poster for his emphasis (which was a bit condescending), but I[/color][/color]
do[color=blue][color=green]
> > agree that a NG is a place for open discussion, even if it means[/color][/color]
discussion[color=blue][color=green]
> > of design decisions on your part.
> >[color=darkred]
> > > it just means you are a closed minded developer that thinks thier way
> > > is the only way.
> > > That's MS junkie thinking.
> > >[/color]
> >
> > Don't be quick to throw stones, friend. In this discussion, who among[/color][/color]
us[color=blue][color=green]
> > has shown an unwillingness to admit when a design is using tools in a[/color][/color]
sloppy[color=blue][color=green]
> > manner to accomplish a goal that shows a strong lack of understanding of
> > efficient or effective data access. That unwillingness has led to much[/color][/color]
of[color=blue][color=green]
> > the frustration that is coming out.
> >
> > Perhaps, if you listen carefully, you may hear the sound of people who[/color][/color]
want[color=blue][color=green]
> > 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.
> > --
> >
> >
> >[/color][/color]

[Relaxin]

Re: Database access sucks!


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.

[color=blue]
>"Nick Malik [Microsoft]" <nickmalik@hotm ail.nospam.com> wrote in message
>news:NIOAd.305 140$HA.192568@a ttbi_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.[/color]

[Relaxin]

Re: Database access sucks!

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 Townson@discuss ions.microsoft. com> wrote in message
news:CFFF6C14-4482-4BA9-B666-1A5BFEAC78C6@mi crosoft.com...[color=blue]
> 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:
>[color=green]
>> 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$wqrb7EH A.3336@TK2MSFTN GP11.phx.gbl...[color=darkred]
>> >
>> > "Relaxin" <me@yourhouse.c om> wrote in message
>> > news:eP8eDTW7EH A.4028@TK2MSFTN GP15.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...w hat 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.(Thi s
>> >> 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...wh ere 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
>> >[/color]
>>
>>
>>[/color][/color]

[Xepol]

RE: Database access sucks!

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]

Re: Database access sucks!

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" <Xepol@discussi ons.microsoft.c om> wrote in message
news:37FE3AA9-1038-4B63-AA3B-9013A5168C23@mi crosoft.com...[color=blue]
> 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![/color]

[J. Buelna - Houston, TX]

Re: Database access sucks!


"Relaxin" <me@yourhouse.c om> wrote in message
news:erXtZsl9EH A.2112@TK2MSFTN GP14.phx.gbl...
[color=blue]
> I have learned dotNet[/color]

bah.

J. Buelna - Houston, TX

[gui_guru]

RE: Database access sucks!

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:
[color=blue]
> 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...w hat 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.(Thi s 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...wh ere 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.
>
>
>
>[/color]

[Richard]

Re: Database access sucks!

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!

[Relaxin]

Re: Database access sucks!

All of what you said, I already know.
[color=blue]
> Forward only, keyset, etc have no place in datasets. How exactly would
> you use a forward only dataset?[/color]

I wouldn't use a forward only dataset, but I sure as heck would use a
keyset.
[color=blue]
> I suggest you take the time to grasp what ADO.NET is before you make
> suggestions on how it could be improved.[/color]

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" <notlikely@borl and.com> wrote in message
news:u7RCUXXBFH A.2788@TK2MSFTN GP15.phx.gbl...[color=blue]
> 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![/color]

[Darren Fuller]

Re: Database access sucks!

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]

Re: Database access sucks!

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:
[color=blue]
> 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![/color]


--
Gerry Hickman (London UK)

[Relaxin]

Re: Database access sucks!

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" <gerry666uk@yah oo.co.uk> wrote in message
news:uKZC1bPJFH A.2648@TK2MSFTN GP14.phx.gbl...[color=blue]
> 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:
>[color=green]
>> 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![/color]
>
>
> --
> Gerry Hickman (London UK)[/color]

[Darren Fuller]

Re: Database access sucks!

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!

[Sean Hederman]

Re: Database access sucks!

"Relaxin" <me@yourhouse.c om> wrote in message
news:eTcG$kPJFH A.1176@TK2MSFTN GP15.phx.gbl...[color=blue]
> I've learned .NET, took my C# certification test (and passed).[/color]

Congratulations .
[color=blue]
> 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.[/color]

Probably a good idea, stick with what you know well if time constraints are
an issue.
[color=blue]
> 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.[/color]

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?
[color=blue]
> 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.[/color]

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.
[color=blue]
> "Gerry Hickman" <gerry666uk@yah oo.co.uk> wrote in message
> news:uKZC1bPJFH A.2648@TK2MSFTN GP14.phx.gbl...[color=green]
>> 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:
>>[color=darkred]
>>> 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![/color]
>>
>>
>> --
>> Gerry Hickman (London UK)[/color]
>
>[/color]