Database access sucks!

[Relaxin]

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.

[Darren Fuller]

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]

Hi Darren,

You are right that a lot of things went downhill with the introduction
of .NET. I currently use JScript with ADO. I can write it in half the
time, with nothing more than a text editor and it runs on any windows
machine regardless of what "framework" is installed, with a few KB of
overhead instead of 65Mb, and fantastic speed. It works with everything
from XML, CSV, Acess JET, SQL Server etc.

I don't agree with you about DAO though, you should NOT use DAO - it sucks.

The main focus of .NET is so that beginners can drag "controls" onto
"forms" without understanding what's going on behind the scenes. If you
need to do some serious programming, leave the .NET at home:)

Darren Fuller wrote:

my two cents..

I stared out using ms vb and ms access and borland delphi. Been using
them since they were all created. So, I've seen quite a few changes. And
this has sometimes been painful.

I agree that you can't compare the objects in ADO.NET with previous
technologies. .Net changed a lot from DAO, ADO, and OLEDB. You can do
everything you used to - just a little differently, and sometimes a
little more work. I also wouldn't compare Borand and MS when it comes to
data access. I love Delphi and C++ builder but I haven't always been
thrilled with their options for data access, much less their
performance. But it was easy and powerful if used correctly.

All that being said..

I was quite upset when I discovered that the "OLD" functionality I was
used to was not incorporated within .NET, specifically the different
types of cursors and how they could be used. In my opinion it was not
necessary to completely remove these "options" from developers because
developers abused how they should be used. Microsoft could have created
a Recordset object as it was in the older versions within .NET and it
still would have value. To say that any object (DataSet, DataReader,
DataTable, etc) in .NET are the same as a Recordset isn't correct,
either. You can use the .NET objects to accomplish any of the old tasks
but they are not the same in their ease of use - you have to do a lot
more work to do some things.

Also, not every application has to scale. I've worked in environments
where I constantly put together small applications in VB or MS ACCESS
and I still used the old components (DAO, ADO) for these applications.
Why would I want a disconnected object from within MS ACCESS that's
going to reside on a client's pc and never go anywhere? For larger -
need to scale applications - ADO.NET is the best choice by far.

Wishing Microsoft would have giving me a Recordset I was famaliar with
does not make me a poor programmer. I don't like it when someone removes
a functionality either - And I know and use ADO.NET, VS.NET as well as
I've used other environments. I adapted. To me, having this
functionality in .NET would not have been a bad thing. But obviously, if
abused like before it could have casted a bad review for .NET. So, I
understand why it was not incorporated. But I don't have to like it. And
I can relate the original posters frustration with it. My only advice is
what most of the responders have offered. Learn ADO.NET as well as you
knew the other environments and make the best of it.

So, I wouldn't say that ADO.NET data access sucks. In all I think it
really is more versatile than pervious technologies. But that old
Recordset objects really rocks, even today when I need it. Too bad Def
Leopard can't say the same.

:-)

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

--
Gerry Hickman (London UK)

[Relaxin]

I've learned .NET, took my C# certification test (and passed).

I now have a larger project that I must get done in a hurry. After much
thinking, I went to Borland's website and purchased C++ Builder 6.

I really tried to convince myself that I could do it faster in C#, but the
fact is, C++ Builder is a truly RAD development environment that doesn't
stop you from doing anything.

Hopefully one day I'll have a project that C# will fit, but if it needs to
be done in a hurry, I'll always fall back to C++ Builder.

"Gerry Hickman" <ge********@yah oo.co.uk> wrote in message
news:uK******** ******@TK2MSFTN GP14.phx.gbl...

Hi Darren,

You are right that a lot of things went downhill with the introduction of
.NET. I currently use JScript with ADO. I can write it in half the time,
with nothing more than a text editor and it runs on any windows machine
regardless of what "framework" is installed, with a few KB of overhead
instead of 65Mb, and fantastic speed. It works with everything from XML,
CSV, Acess JET, SQL Server etc.

I don't agree with you about DAO though, you should NOT use DAO - it
sucks.

The main focus of .NET is so that beginners can drag "controls" onto
"forms" without understanding what's going on behind the scenes. If you
need to do some serious programming, leave the .NET at home:)

Darren Fuller wrote:

my two cents..

I stared out using ms vb and ms access and borland delphi. Been using
them since they were all created. So, I've seen quite a few changes. And
this has sometimes been painful.

I agree that you can't compare the objects in ADO.NET with previous
technologies. .Net changed a lot from DAO, ADO, and OLEDB. You can do
everything you used to - just a little differently, and sometimes a
little more work. I also wouldn't compare Borand and MS when it comes to
data access. I love Delphi and C++ builder but I haven't always been
thrilled with their options for data access, much less their
performance. But it was easy and powerful if used correctly.

All that being said..

I was quite upset when I discovered that the "OLD" functionality I was
used to was not incorporated within .NET, specifically the different
types of cursors and how they could be used. In my opinion it was not
necessary to completely remove these "options" from developers because
developers abused how they should be used. Microsoft could have created
a Recordset object as it was in the older versions within .NET and it
still would have value. To say that any object (DataSet, DataReader,
DataTable, etc) in .NET are the same as a Recordset isn't correct,
either. You can use the .NET objects to accomplish any of the old tasks
but they are not the same in their ease of use - you have to do a lot
more work to do some things. Also, not every application has to scale.
I've worked in environments
where I constantly put together small applications in VB or MS ACCESS
and I still used the old components (DAO, ADO) for these applications.
Why would I want a disconnected object from within MS ACCESS that's
going to reside on a client's pc and never go anywhere? For larger -
need to scale applications - ADO.NET is the best choice by far. Wishing
Microsoft would have giving me a Recordset I was famaliar with
does not make me a poor programmer. I don't like it when someone removes
a functionality either - And I know and use ADO.NET, VS.NET as well as
I've used other environments. I adapted. To me, having this
functionality in .NET would not have been a bad thing. But obviously, if
abused like before it could have casted a bad review for .NET. So, I
understand why it was not incorporated. But I don't have to like it. And
I can relate the original posters frustration with it. My only advice is
what most of the responders have offered. Learn ADO.NET as well as you
knew the other environments and make the best of it. So, I wouldn't say
that ADO.NET data access sucks. In all I think it
really is more versatile than pervious technologies. But that old
Recordset objects really rocks, even today when I need it. Too bad Def
Leopard can't say the same.

:-)

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

--
Gerry Hickman (London UK)

[Darren Fuller]

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]

"Relaxin" <me@yourhouse.c om> wrote in message
news:eT******** ******@TK2MSFTN GP15.phx.gbl...

I've learned .NET, took my C# certification test (and passed).
Congratulations .
I now have a larger project that I must get done in a hurry. After much
thinking, I went to Borland's website and purchased C++ Builder 6.
Probably a good idea, stick with what you know well if time constraints are
an issue.
I really tried to convince myself that I could do it faster in C#, but the
fact is, C++ Builder is a truly RAD development environment that doesn't
stop you from doing anything.
Sorry, what exactly does C# stop you from doing? I've used C# and C++
Builder and I found Builder to be MUCH less productive. Then again, I do
come from a VS background, so maybe that was it. Could it perhaps be that
you're just more used to Builder?
Hopefully one day I'll have a project that C# will fit, but if it needs to
be done in a hurry, I'll always fall back to C++ Builder.
I'm struggling to understand what kind of project C# doesn't fit? Are you
writing device drivers or something? If you don't fit a tool, that does not
imply that the tool doesn't fit a job.
"Gerry Hickman" <ge********@yah oo.co.uk> wrote in message
news:uK******** ******@TK2MSFTN GP14.phx.gbl...

Hi Darren,

You are right that a lot of things went downhill with the introduction of
.NET. I currently use JScript with ADO. I can write it in half the time,
with nothing more than a text editor and it runs on any windows machine
regardless of what "framework" is installed, with a few KB of overhead
instead of 65Mb, and fantastic speed. It works with everything from XML,
CSV, Acess JET, SQL Server etc.

I don't agree with you about DAO though, you should NOT use DAO - it
sucks.

The main focus of .NET is so that beginners can drag "controls" onto
"forms" without understanding what's going on behind the scenes. If you
need to do some serious programming, leave the .NET at home:)

Darren Fuller wrote:

my two cents..

I stared out using ms vb and ms access and borland delphi. Been using
them since they were all created. So, I've seen quite a few changes. And
this has sometimes been painful.

I agree that you can't compare the objects in ADO.NET with previous
technologies. .Net changed a lot from DAO, ADO, and OLEDB. You can do
everything you used to - just a little differently, and sometimes a
little more work. I also wouldn't compare Borand and MS when it comes to
data access. I love Delphi and C++ builder but I haven't always been
thrilled with their options for data access, much less their
performance. But it was easy and powerful if used correctly.

All that being said..

I was quite upset when I discovered that the "OLD" functionality I was
used to was not incorporated within .NET, specifically the different
types of cursors and how they could be used. In my opinion it was not
necessary to completely remove these "options" from developers because
developers abused how they should be used. Microsoft could have created
a Recordset object as it was in the older versions within .NET and it
still would have value. To say that any object (DataSet, DataReader,
DataTable, etc) in .NET are the same as a Recordset isn't correct,
either. You can use the .NET objects to accomplish any of the old tasks
but they are not the same in their ease of use - you have to do a lot
more work to do some things. Also, not every application has to scale.
I've worked in environments
where I constantly put together small applications in VB or MS ACCESS
and I still used the old components (DAO, ADO) for these applications.
Why would I want a disconnected object from within MS ACCESS that's
going to reside on a client's pc and never go anywhere? For larger -
need to scale applications - ADO.NET is the best choice by far. Wishing
Microsoft would have giving me a Recordset I was famaliar with
does not make me a poor programmer. I don't like it when someone removes
a functionality either - And I know and use ADO.NET, VS.NET as well as
I've used other environments. I adapted. To me, having this
functionality in .NET would not have been a bad thing. But obviously, if
abused like before it could have casted a bad review for .NET. So, I
understand why it was not incorporated. But I don't have to like it. And
I can relate the original posters frustration with it. My only advice is
what most of the responders have offered. Learn ADO.NET as well as you
knew the other environments and make the best of it. So, I wouldn't say
that ADO.NET data access sucks. In all I think it
really is more versatile than pervious technologies. But that old
Recordset objects really rocks, even today when I need it. Too bad Def
Leopard can't say the same.

:-)

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

--
Gerry Hickman (London UK)

[Relaxin]

"Sean Hederman" <us***@blogentr y.com> wrote in message
news:d0******** **@ctb-nnrp2.saix.net. ..

I now have a larger project that I must get done in a hurry. After much
thinking, I went to Borland's website and purchased C++ Builder 6.
Probably a good idea, stick with what you know well if time constraints
are an issue.

I really tried to convince myself that I could do it faster in C#, but
the fact is, C++ Builder is a truly RAD development environment that
doesn't stop you from doing anything.

I'm struggling to understand what kind of project C# doesn't fit? Are you writing device drivers or something? If you don't fit a tool, that does
not imply that the tool doesn't fit a job.>

The Job that "I" have found that C# don't fit is when you need to load a lot
of data and 80% of it is varies pictures.

I wish C#'s dataset had the ability to keep data at the server side instead
of loading it all to the client.

Plus with .NET non-determisitic garbage collector, the client would running
out of memory or the system would become very sluggish.

Also, the inability to seperate your business logic from your interface.

The inability to change the key in the Keypress event.

The disassociation of your dataset from what the user is doing to it through
the components (mainly the grid).

And a semi-clunky IDE, although, there some things in the IDE that are
better than Borland's.

Also, in C# (.NET 2.0), why do you need to select the class name refactoring
meun option. The IDE already knows the name of the class, how about just
automatically "refactorin g" when I change the name...oh, and how about
changing the name of the events (automatically) also.

The product is just to immature.

I just felt I would spend more time fighting and working around issues,
rather than writing code.

Don't get me wrong, there is plenty to like about C#, it just needs to
polished up.

[Sean Hederman]

"Relaxin" <me@yourhouse.c om> wrote in message
news:%2******** **********@TK2M SFTNGP09.phx.gb l...

"Sean Hederman" <us***@blogentr y.com> wrote in message
news:d0******** **@ctb-nnrp2.saix.net. ..

I now have a larger project that I must get done in a hurry. After much
thinking, I went to Borland's website and purchased C++ Builder 6.
Probably a good idea, stick with what you know well if time constraints
are an issue.

I really tried to convince myself that I could do it faster in C#, but
the fact is, C++ Builder is a truly RAD development environment that
doesn't stop you from doing anything.

I'm struggling to understand what kind of project C# doesn't fit? Are you

writing device drivers or something? If you don't fit a tool, that does
not imply that the tool doesn't fit a job.>

The Job that "I" have found that C# don't fit is when you need to load a
lot of data and 80% of it is varies pictures.

Have a look at
http://www.windowsforms.net/Applicat...=50&tabindex=8

It's a .NET app that serves photos up to Windows Forms, Web Forms and CE
clients.
I wish C#'s dataset had the ability to keep data at the server side
instead of loading it all to the client.
Since a Dataset is a client-side disconnected data source this would
completely be against it's design. If you want to iterate through back-end
data with more fine-grained control, use the IDataReader implementations .
Plus with .NET non-determisitic garbage collector, the client would
running out of memory or the system would become very sluggish.
Actually, it doesn't matter what system you were running, pulling back a
databases worth of images into memory will result in the same symptoms.
Also, the inability to seperate your business logic from your interface
I'm not sure what you're trying to get at here. If you're trying to say that
..NET doesn't support n-tier architectures, you're very, very wrong. If
you're trying to talk about the control of the actual UI being separated
from the forms code itself, have a look at the Command pattern and
http://msdn.microsoft.com/library/de...html/uipab.asp
The inability to change the key in the Keypress event.
Events are not meant to be two-way data transfer mechanisms. About the only
time events allow parameters to be passed back is when the event arguments
support a Handled property. If you want to manipulate the text based on what
key was pressed you can just do that. Another option would be to use the
SendKeys class after setting e.Handled = true.
The disassociation of your dataset from what the user is doing to it
through the components (mainly the grid).
Dataset.Clone()
And a semi-clunky IDE, although, there some things in the IDE that are
better than Borland's.
Matter of taste I suppose. I personally find Borlands IDE horribly clunky.
Also, in C# (.NET 2.0), why do you need to select the class name
refactoring meun option. The IDE already knows the name of the class, how
about just automatically "refactorin g" when I change the name
Dunno about you, but I don't like the IDE doing stuff without my knowledge.
What if I want to change the class name without anything else changing?
...oh, and how about changing the name of the events (automatically) also.
Doesn't really apply to me, since I don't use the default event names
anyway.
The product is just to immature.
Not for me, not for my team, not for my company. We find it an absolute
dream.
I just felt I would spend more time fighting and working around issues,
rather than writing code.
Exactly why I like .NET ;D

Isn't taste a strange thing?
Don't get me wrong, there is plenty to like about C#, it just needs to
polished up.

[Jeff Louie]

Sean.. I think that you can automate some of the repetitive steps by
writing your own Printing and Query Framework.

http://www.geocities.com/jeff_louie/..._framework.htm
http://www.geocities.com/jeff_louie/..._framework.htm

Regards,
Jeff
Sorry, what exactly does C# stop you from doing?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Relaxin]

"Sean Hederman" <us***@blogentr y.com> wrote in message
news:d1******** **@ctb-nnrp2.saix.net. ..

"Relaxin" <me@yourhouse.c om> wrote in message
news:%2******** **********@TK2M SFTNGP09.phx.gb l...

The Job that "I" have found that C# don't fit is when you need to load a
lot of data and 80% of it is varies pictures.

Have a look at
http://www.windowsforms.net/Applicat...=50&tabindex=8

It's a .NET app that serves photos up to Windows Forms, Web Forms and CE
clients.

I wish C#'s dataset had the ability to keep data at the server side
instead of loading it all to the client.

Since a Dataset is a client-side disconnected data source this would
completely be against it's design. If you want to iterate through back-end
data with more fine-grained control, use the IDataReader implementations .

But, ADO supported server-side connections and I need it databound to a
grid.
So, the DataReader won't help.

Plus with .NET non-determisitic garbage collector, the client would
running out of memory or the system would become very sluggish.

Actually, it doesn't matter what system you were running, pulling back a
databases worth of images into memory will result in the same symptoms.

Not if most of it is keep on the server instead of the client.

Also, the inability to seperate your business logic from your interface

I'm not sure what you're trying to get at here. If you're trying to say
that .NET doesn't support n-tier architectures, you're very, very wrong.
If you're trying to talk about the control of the actual UI being
separated from the forms code itself, have a look at the Command pattern
and
http://msdn.microsoft.com/library/de...html/uipab.asp

I'm not talking about n-tier, I mean not having to place you business logic
directly underneath your UI controls.
Borland handles this by means of a datamodule...wh ich is where you place
your business logic and totally seperated from your interface.

The inability to change the key in the Keypress event.

Events are not meant to be two-way data transfer mechanisms. About the
only time events allow parameters to be passed back is when the event
arguments support a Handled property. If you want to manipulate the text
based on what key was pressed you can just do that. Another option would
be to use the SendKeys class after setting e.Handled = true.

Borland allowed it, so you can't say it's not meant to be. It's just a poor
implementation on MS part.

The disassociation of your dataset from what the user is doing to it
through the components (mainly the grid).

Dataset.Clone()

???... This just make a skeleton of your dataset without the data, now you
are also disassociated from your data.

And a semi-clunky IDE, although, there some things in the IDE that are
better than Borland's.

Matter of taste I suppose. I personally find Borlands IDE horribly clunky.

Also, in C# (.NET 2.0), why do you need to select the class name
refactoring meun option. The IDE already knows the name of the class,
how about just automatically "refactorin g" when I change the name

Dunno about you, but I don't like the IDE doing stuff without my
knowledge. What if I want to change the class name without anything else
changing?

We are talking about changing the class name...you have to change it
everywhere if you want it to compile.
Are you just making up stuff to try to support MS decisions?

...oh, and how about changing the name of the events (automatically)
also.

Doesn't really apply to me, since I don't use the default event names
anyway.

The product is just to immature.

Not for me, not for my team, not for my company. We find it an absolute
dream.

I just felt I would spend more time fighting and working around issues,
rather than writing code.

Exactly why I like .NET ;D

Isn't taste a strange thing?

Again, I think you are just making up arguments to support your decision.

I want .NET to succeed, I don't want to go back to Borland (for business
reasons), but I feel that currently I have no choice.

[Sean Hederman]

"Relaxin" <me@yourhouse.c om> wrote in message
news:eK******** ******@tk2msftn gp13.phx.gbl...

"Sean Hederman" <us***@blogentr y.com> wrote in message
news:d1******** **@ctb-nnrp2.saix.net. ..

"Relaxin" <me@yourhouse.c om> wrote in message
news:%2******** **********@TK2M SFTNGP09.phx.gb l...

The Job that "I" have found that C# don't fit is when you need to load a
lot of data and 80% of it is varies pictures.

Have a look at
http://www.windowsforms.net/Applicat...=50&tabindex=8

It's a .NET app that serves photos up to Windows Forms, Web Forms and CE
clients.

I wish C#'s dataset had the ability to keep data at the server side
instead of loading it all to the client.

Since a Dataset is a client-side disconnected data source this would
completely be against it's design. If you want to iterate through
back-end data with more fine-grained control, use the IDataReader
implementations .

But, ADO supported server-side connections and I need it databound to a
grid.
So, the DataReader won't help.

It looks like in this scenario you would have to use manual binding.
Needless to say Dataset (being disconnected) cannot support server-side
cursors.

Plus with .NET non-determisitic garbage collector, the client would
running out of memory or the system would become very sluggish.

Actually, it doesn't matter what system you were running, pulling back a
databases worth of images into memory will result in the same symptoms.

Not if most of it is keep on the server instead of the client.

Also, the inability to seperate your business logic from your interface

I'm not sure what you're trying to get at here. If you're trying to say
that .NET doesn't support n-tier architectures, you're very, very wrong.
If you're trying to talk about the control of the actual UI being
separated from the forms code itself, have a look at the Command pattern
and
http://msdn.microsoft.com/library/de...html/uipab.asp

I'm not talking about n-tier, I mean not having to place you business
logic directly underneath your UI controls.
Borland handles this by means of a datamodule...wh ich is where you place
your business logic and totally seperated from your interface.

Again, I don't place my business logic directly under my controls. It is in
a separate tier completely separated from my interface. The interface is
little more than simple commands executing components of the business logic
& presentation logic.

The inability to change the key in the Keypress event.

Events are not meant to be two-way data transfer mechanisms. About the
only time events allow parameters to be passed back is when the event
arguments support a Handled property. If you want to manipulate the text
based on what key was pressed you can just do that. Another option would
be to use the SendKeys class after setting e.Handled = true.

Borland allowed it, so you can't say it's not meant to be. It's just a
poor implementation on MS part.

..NET is different from the Borland libraries and has different design
guidelines and principles. Under the .NET design principles it doesn't make
sense to have events modifying data, Borland seemed to think that was OK.
Now, given a multicast event to KeyPress, if the one event sink indicates
that the key event should be cancelled, another indicates that it should be
changed to 'A' and another indicates that instead it should be 'B', what is
your control supposed to do?

In .NET this cannot happen because the only input the event sinks have is
whether the key event should be cancelled or not, and that's a simple
boolean OR. Now, it's your prerogative to say that this is poor
implementation, but I personally feel that an implementation which allowed a
scenario like I just described would be a poor implementation.

The disassociation of your dataset from what the user is doing to it
through the components (mainly the grid).

Dataset.Clone()

???... This just make a skeleton of your dataset without the data, now you
are also disassociated from your data.

Sorry, Dataset.Copy(), my mistake. One thing you don't seem to be grokking
is that with Dataset you're ALWAYS disconnected from your data.

And a semi-clunky IDE, although, there some things in the IDE that are
better than Borland's.

Matter of taste I suppose. I personally find Borlands IDE horribly
clunky.

Also, in C# (.NET 2.0), why do you need to select the class name
refactoring meun option. The IDE already knows the name of the class,
how about just automatically "refactorin g" when I change the name

Dunno about you, but I don't like the IDE doing stuff without my
knowledge. What if I want to change the class name without anything else
changing?

We are talking about changing the class name...you have to change it
everywhere if you want it to compile.
Are you just making up stuff to try to support MS decisions?

No, I just don't like tools doing things automatically without me knowing
about it. At the very least I'd like some sort of popup, to allow me to
agree or disagree, but that could be very annoying. I like my changes to my
code to be based on conscious decisions on my part, rather than on some tool
trying to "help" me when I may or may not need help. If I want help
refactoring, I ask my tool for it.

...oh, and how about changing the name of the events (automatically)
also.

Doesn't really apply to me, since I don't use the default event names
anyway.

The product is just to immature.

Not for me, not for my team, not for my company. We find it an absolute
dream.

I just felt I would spend more time fighting and working around issues,
rather than writing code.

Exactly why I like .NET ;D

Isn't taste a strange thing?

Again, I think you are just making up arguments to support your decision.

I want .NET to succeed, I don't want to go back to Borland (for business
reasons), but I feel that currently I have no choice.

Arguments? I'm not making up arguments. I'm trying to get across to you that
not everyone feels that the Borland tools are better than .NET, and trying
to indicate that a major reason why might be taste. So basically my point is
that it is my *opinion* that .NET is fine for what I do, and it is your
*opinion* that Borland is better suited. You don't like the fact that .NET
does not do things the Borland(TM) way, and that's fine, if you prefer the
Borland way by all means use it.

Just don't come along and make trashy comments without being able to back
them up with a little more than "Borland does it...so it's just poor MS
implementation" .