Re: Some new (or old ?) information

[Dennes Torres]

Hi!

I found this text at the address http://msdn.microsoft.com/library/de...doplusnet.asp:

"Server Cursors

"As I described earlier, ADO's recordset was really a conflation of
three different APIs -— the interface for a forward-only stream of data,
the API for a client-side cache (the OLE DB cursor engine), and an abstraction
for exposing updateable, scrollable cursors. The first two map to the ADO+
DataReader and DataSet classes, respectively. So what happened to server
cursors? ADO+ currently does not have intrinsic support for a general-purpose
server cursor object. The key reason for this is that for this kind of functionality,
data sources tend to differ in their implementation enough that exposing
a single abstraction that hides the details from the user becomes difficult.

"Since most applications require only the first two abstractions anyway,
ADO+ relies on ADO for server cursor support, at least for the current beta
of Visual Studio .NET. ADO is readily accessible from the .NET Framework
through the COM Interop services of the CLR. The TLBIMP program, shipped
with the SDK, can be used to import a COM type library and emit metadata
that can be consumed by the CLR. Therefore, for developers who really want
ADO semantics, or ones who rely heavily on positioned updates and connected
scrollable cursors, using ADO through the Interop layer is the right solution."

This mean that client/server programmers will need to forget RAD an things
like Data Environment to learn a new language in wich they need to do all
the data manipulation in code, because the visual components don't support
server-side cursors that the client/server environment need? I really don't
think this will work.

I tried to use VB6 components in VB.NET: I used the ADODC and DataGrid
in VB.NET. After configured ADODC properties, I couldn't bind the DataGrid
to the ADODC control, ADODC wasn't listed in datasource property. I tried
by code but it doesn't work. I think I made something wrong, but it isn't
a trivial task. So the question is:

Why should I use VB.NET if:

A) My systems work well with the language that I already know, VB 6.0
B) I can't user VB.NET power, because it wasn't made for client/server
C) I can't even user VB 6.0 components with VB.NET, it's too difficult (more
difficult than VB 6.0 and with nothing better, I mean)

Am I forgetting something? I'm surprised that nobody has notice this before!
What am I forgetting?

[]'s

Dennes Torres

[Patrick Troughton]

>This mean that client/server programmers will need to forget RAD an things
>like Data Environment to learn a new language in wich they need to do all
>the data manipulation in code, because the visual components don't support
>server-side cursors that the client/server environment need? I really don't
>think this will work.

There are a lot of drag and drop RAD tools in .NET that let you do lots of
data work without writing code. Honestly, I'm not a big fan of data binding
and prefer to write my own code so I haven't really tried them, but they
are there. Have you had a look at Database Programming with Visual Basic.NET
by Apress? I'm sure it covers the new RAD tools in more detail than I can
provide....

http://www.apress.com/catalog/book/1893115291/

/Pat

[Dennes Torres]

Hi !

I know that. What I'm saying is that if I want to use server-side cursors
I couldn't user RAD, because I will need to use ADO by code. All the RAD
in .NET use client-side cursors.

I think this will be a big problem in migration process, specially in migration
process made by unprepared people.

[]'s

Dennes Torres

"Patrick Troughton" <Patrick@Troughton.com> wrote:
>
>>This mean that client/server programmers will need to forget RAD an things
>>like Data Environment to learn a new language in wich they need to do all
>>the data manipulation in code, because the visual components don't support
>>server-side cursors that the client/server environment need? I really don't
>>think this will work.
>
>There are a lot of drag and drop RAD tools in .NET that let you do lots
of
>data work without writing code. Honestly, I'm not a big fan of data binding
>and prefer to write my own code so I haven't really tried them, but they
>are there. Have you had a look at Database Programming with Visual Basic.NET
>by Apress? I'm sure it covers the new RAD tools in more detail than I can
>provide....
>
>http://www.apress.com/catalog/book/1893115291/
>
>/Pat

[Rob Teixeira]

Hello Dennes,
Nice to see another name from Brazil!

I think anyone involved with migration will tell you that it is an exercise
that's going to require some thought and planning. In some cases, it will
be much easier than others. Middle-tier business logic components will be
extremely simple, for example. UI code will be a more involved process.
People like Dan Appleman have given this aspect of development a lot of thought
(he has a great book about migration!), but even he refuses to say that it
is a painless process for all cases.

In this respect though, server-side cursors present such a scalability problem
(and that's been known for decades), that I have to wonder how many people
really use it (within a VB context)?
That's a real question by the way
Feel free to post your thoughts. I'm curious now.

-Rob


"Dennes Torres" <dennes@bufaloinfo.com.br> wrote:
>
>
>Hi !
>
>I know that. What I'm saying is that if I want to use server-side cursors
>I couldn't user RAD, because I will need to use ADO by code. All the RAD
>in .NET use client-side cursors.
>
>I think this will be a big problem in migration process, specially in migration
>process made by unprepared people.
>
>[]'s
>
>Dennes Torres
>

[Dennes Torres]

Hi, Rob !

A lot, very lot, people use server-side cursors. Think in data grid, for
example. I don't want to transfer all the records just for the user look
to the grid and close the window. So I can transfer just a few records and
get the rest just if needed, if the user press "page down", for example.

Some people can say that a good interface can avoid data grids, for example.
I agree that a lot of client/server interfaces can avoid it, but do you think
every interface can ? I don't think so.

So, the problem is not the migration, but even the creation of new application.
Is possible to design every (EVERY!) user interface avoiding the use of data
grid and navigation screens and using client side cursors ? I don't think
so.

The second problem is the knowledge of the people. In Brazil we have a lot
(a lot !) of people that even know client/server well. The server-side cursor
is a bless (is it correct ?) for bad user interfaces. So, when all this people
begin to use VB.NET we will see lots and lots of problems in TI area.

[]'s

Dennes Torres



"Rob Teixeira" <RobTeixeira@@msn.com> wrote:
>
>
>Hello Dennes,
>Nice to see another name from Brazil!
>
>I think anyone involved with migration will tell you that it is an exercise
>that's going to require some thought and planning. In some cases, it will
>be much easier than others. Middle-tier business logic components will be
>extremely simple, for example. UI code will be a more involved process.
>People like Dan Appleman have given this aspect of development a lot of
thought
>(he has a great book about migration!), but even he refuses to say that
it
>is a painless process for all cases.
>
>In this respect though, server-side cursors present such a scalability problem
>(and that's been known for decades), that I have to wonder how many people
>really use it (within a VB context)?
>That's a real question by the way
>Feel free to post your thoughts. I'm curious now.
>
>-Rob
>
>
>"Dennes Torres" <dennes@bufaloinfo.com.br> wrote:
>>
>>
>>Hi !
>>
>>I know that. What I'm saying is that if I want to use server-side cursors
>>I couldn't user RAD, because I will need to use ADO by code. All the RAD
>>in .NET use client-side cursors.
>>
>>I think this will be a big problem in migration process, specially in migration
>>process made by unprepared people.
>>
>>[]'s
>>
>>Dennes Torres
>>
>

[Mike Mitchell]

On 15 Dec 2001 00:25:39 GMT, "Dennes Torres"
<dennes@bufaloinfo.com.br> wrote:

>Some people can say that a good interface can avoid data grids, for example.

Why avoid data grids? They are the best all-round presentational tool
for displaying and manipulating data since the spreadsheet was
invented. Tree views have their place, but a grid, especially a highly
configurable one like VsFlexGrid Pro, allows users to do anything they
need -- and stuff they don't.

Ask yourself, why are there so many grids on the market? It's what
people -- developers and clients -- want.

MM

[Dennes Torres]

Hi, Mike !

That's what I'm saying and trying to discover to/from everyone !

The fact is : Without server side cursors, whe can't use datagrids in winforms/vb.net
any more, because the network traffic will be too big !

A lot of people are saying that an interface with a grid is a bad interface.
I agree in part. Some interfaces use more grids than necessary and could
avoid it, but a lot of interfaces can't and, without server-side cursors,
this interfaces can't be made in winforms !

[]'s

Dennes Torres


kylix_is@yahoo.co.uk (Mike Mitchell) wrote:
>On 15 Dec 2001 00:25:39 GMT, "Dennes Torres"
><dennes@bufaloinfo.com.br> wrote:
>
>>Some people can say that a good interface can avoid data grids, for example.
>
>Why avoid data grids? They are the best all-round presentational tool
>for displaying and manipulating data since the spreadsheet was
>invented. Tree views have their place, but a grid, especially a highly
>configurable one like VsFlexGrid Pro, allows users to do anything they
>need -- and stuff they don't.
>
>Ask yourself, why are there so many grids on the market? It's what
>people -- developers and clients -- want.
>
>MM

[Markn]

You can still use datagrids. You may not be able to use databound datagrids.
Not being able to do this may slow down development but is better in the
long run. Suppling data to the grid through an interface (as Patrick suggested)
is the way to go. I do this in another language with grids and it works
well.

Mark

"Dennes Torres" <dennes@bufaloinfo.com.br> wrote:
>
>
>Hi, Mike !
>
>That's what I'm saying and trying to discover to/from everyone !
>
>The fact is : Without server side cursors, whe can't use datagrids in winforms/vb.net
>any more, because the network traffic will be too big !
>
>A lot of people are saying that an interface with a grid is a bad interface.
>I agree in part. Some interfaces use more grids than necessary and could
>avoid it, but a lot of interfaces can't and, without server-side cursors,
>this interfaces can't be made in winforms !
>
>[]'s
>
>Dennes Torres
>
>
>kylix_is@yahoo.co.uk (Mike Mitchell) wrote:
>>On 15 Dec 2001 00:25:39 GMT, "Dennes Torres"
>><dennes@bufaloinfo.com.br> wrote:
>>
>>>Some people can say that a good interface can avoid data grids, for example.
>>
>>Why avoid data grids? They are the best all-round presentational tool
>>for displaying and manipulating data since the spreadsheet was
>>invented. Tree views have their place, but a grid, especially a highly
>>configurable one like VsFlexGrid Pro, allows users to do anything they
>>need -- and stuff they don't.
>>
>>Ask yourself, why are there so many grids on the market? It's what
>>people -- developers and clients -- want.
>>
>>MM
>

[Dennes Torres]

"Markn" <mnuttall@nospam.com> wrote:
>
>You can still use datagrids. You may not be able to use databound datagrids.
> Not being able to do this may slow down development but is better in the

Hi!

If I can't use Data bound, why it's still there ? There is something wrong
!

[]'s

Dennes Torres


>long run. Suppling data to the grid through an interface (as Patrick suggested)
>is the way to go. I do this in another language with grids and it works
>well.
>
>Mark
>
>"Dennes Torres" <dennes@bufaloinfo.com.br> wrote:
>>
>>
>>Hi, Mike !
>>
>>That's what I'm saying and trying to discover to/from everyone !
>>
>>The fact is : Without server side cursors, whe can't use datagrids in winforms/vb.net
>>any more, because the network traffic will be too big !
>>
>>A lot of people are saying that an interface with a grid is a bad interface.
>>I agree in part. Some interfaces use more grids than necessary and could
>>avoid it, but a lot of interfaces can't and, without server-side cursors,
>>this interfaces can't be made in winforms !
>>
>>[]'s
>>
>>Dennes Torres
>>
>>
>>kylix_is@yahoo.co.uk (Mike Mitchell) wrote:
>>>On 15 Dec 2001 00:25:39 GMT, "Dennes Torres"
>>><dennes@bufaloinfo.com.br> wrote:
>>>
>>>>Some people can say that a good interface can avoid data grids, for example.
>>>
>>>Why avoid data grids? They are the best all-round presentational tool
>>>for displaying and manipulating data since the spreadsheet was
>>>invented. Tree views have their place, but a grid, especially a highly
>>>configurable one like VsFlexGrid Pro, allows users to do anything they
>>>need -- and stuff they don't.
>>>
>>>Ask yourself, why are there so many grids on the market? It's what
>>>people -- developers and clients -- want.
>>>
>>>MM
>>
>

[Patrick Troughton]

"Dennes Torres" <dennes@bufaloinfo.com.br> wrote:
>Hi!
>
>If I can't use Data bound, why it's still there ? There is something wrong
>!

I think you might have lost me. You *can* use databinding in .NET. We discussed
this a few times already...

/Pat

[Dennes Torres]

Hi!

No, you lost me.

I can't use databind with server-side cursors.

I can't use databind use client-side cursors because I will create lots of
network traffic.

For everything else I will need to make lots of code.

So, I can't use databinding.

[]'s

Dennes Torres


"Patrick Troughton" <Patrick@Troughton.com> wrote:
>
>"Dennes Torres" <dennes@bufaloinfo.com.br> wrote:
>>Hi!
>>
>>If I can't use Data bound, why it's still there ? There is something wrong
>>!
>
>I think you might have lost me. You *can* use databinding in .NET. We discussed
>this a few times already...
>
>/Pat

[Patrick Troughton]

"Dennes Torres" <dennes@bufaloinfo.com.br> wrote:
>
>I can't use databind with server-side cursors.

Not accurate - you can with DataReaders. We went over this before.

>I can't use databind use client-side cursors because I will create lots
of
>network traffic.

You'll still get network traffic with server side cursors because the data
still has to be moved across. If you're so concerned about network traffic,
have you thought about putting your database objects on the database itself?
This would minimize network traffic while allowing you to do databinding.
That's what you want, right?

>For everything else I will need to make lots of code.

That's your choice.

>So, I can't use databinding.

Yes, you can. You're just choosing not to.

Can I have a little clarification? Are you asking for advice or do you just
want to complain? If the latter, there's no point in us trying to help you
because no matter what we suggest, you're not going to be happy.

/Pat

[Patrick Troughton]

"Patrick Troughton" <Patrick@Troughton.com> wrote:
>
>have you thought about putting your database objects on the database
>itself?

To be clear, I meant to say .... "on the database SERVER itself".

/Pat

[MarkN]

Didn't mean impossible. My theory why these tools exist: For people who can't
live without them and backwards compatiblity. They are not a good way to
do enterprise development. What Patrick is saying is right and is the reason
I gave up on them years ago. They are bad for so many reasons )(Network
traffic/tie UI to database/Wierd errors). Bite the bullet(unless one lives
where MM does and aren't allowed to have any) and get rid of them when you
move to .NET. ALOT (I would venture saying the majority) of apps here in
the States will need to do the same thing so don't feel like you are alone.


>
>If I can't use Data bound, why it's still there ? There is something wrong
>!
>
>[]'s
>
>Dennes Torres
>
>
>>long run. Suppling data to the grid through an interface (as Patrick suggested)
>>is the way to go. I do this in another language with grids and it works
>>well.
>>
>>Mark
>>
>>"Dennes Torres" <dennes@bufaloinfo.com.br> wrote:
>>>
>>>
>>>Hi, Mike !
>>>
>>>That's what I'm saying and trying to discover to/from everyone !
>>>
>>>The fact is : Without server side cursors, whe can't use datagrids in
winforms/vb.net
>>>any more, because the network traffic will be too big !
>>>
>>>A lot of people are saying that an interface with a grid is a bad interface.
>>>I agree in part. Some interfaces use more grids than necessary and could
>>>avoid it, but a lot of interfaces can't and, without server-side cursors,
>>>this interfaces can't be made in winforms !
>>>
>>>[]'s
>>>
>>>Dennes Torres
>>>
>>>
>>>kylix_is@yahoo.co.uk (Mike Mitchell) wrote:
>>>>On 15 Dec 2001 00:25:39 GMT, "Dennes Torres"
>>>><dennes@bufaloinfo.com.br> wrote:
>>>>
>>>>>Some people can say that a good interface can avoid data grids, for
example.
>>>>
>>>>Why avoid data grids? They are the best all-round presentational tool
>>>>for displaying and manipulating data since the spreadsheet was
>>>>invented. Tree views have their place, but a grid, especially a highly
>>>>configurable one like VsFlexGrid Pro, allows users to do anything they
>>>>need -- and stuff they don't.
>>>>
>>>>Ask yourself, why are there so many grids on the market? It's what
>>>>people -- developers and clients -- want.
>>>>
>>>>MM
>>>
>>
>

[Vlad Ivanov]

>>>>The fact is : Without server side cursors, whe can't use datagrids in
>winforms/vb.net
>>>>any more, because the network traffic will be too big !

This is a concensus of so called professional community???

What is wrong with disconnected recordsets forwarded ByVal to client-side
to display a grid? Don't even start with network traffic - you don't need
to show all of the available records if you provide a decent interface to
query the data beforhand.