Why can't M$ allow .NET developers to run ANSI standard SQL queries on
ADO.NET datatables/datasets (SELECT, INSERT, UPDATE, DELETE)?

This will allow other developers to learn ANSI syntax and be able to utilize
SQL Server without much learning curve. I bet there are people out there
that have programmed in .NET but have NEVER written a SQL SELECT statement.
That is scary!!

The ability to requery data on the client is an essential tool for every
developer, unless you never save your data. They do give you dataviews, but
you cannot do a DISTINCT listing on those. They only give you the ability
to order data (SET ORDER TO), filter data (SET FILTER TO), and some
others...

HEY M$ - WE NEED TO MANIPULATE DATA ON OTHER PLACES BEYOND STORED
PROCEDURES!!!!!!! THAT IS KEY TO OUR JOB!!!!!

By the way - if you want to do a DISTINCT listing, here is how:
http://support.microsoft.com/default...b;en-us;326176

This will only work for a distinct value in 1 field.

"Ty Salistean" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Why can't M$ allow .NET developers to run ANSI standard SQL queries on
> ADO.NET datatables/datasets (SELECT, INSERT, UPDATE, DELETE)?
>
> This will allow other developers to learn ANSI syntax and be able to
utilize
> SQL Server without much learning curve. I bet there are people out there
> that have programmed in .NET but have NEVER written a SQL SELECT
statement.
> That is scary!!
>
> The ability to requery data on the client is an essential tool for every
> developer, unless you never save your data. They do give you dataviews,
but
> you cannot do a DISTINCT listing on those. They only give you the ability
> to order data (SET ORDER TO), filter data (SET FILTER TO), and some
> others...
>
> HEY M$ - WE NEED TO MANIPULATE DATA ON OTHER PLACES BEYOND STORED
> PROCEDURES!!!!!!! THAT IS KEY TO OUR JOB!!!!!
>
>

Ty Salistean <(E-Mail Removed)> wrote:
> Why can't M$ allow .NET developers to run ANSI standard SQL queries on
> ADO.NET datatables/datasets (SELECT, INSERT, UPDATE, DELETE)?

Well, for a start that would require a full SQL engine built into .NET.

> This will allow other developers to learn ANSI syntax and be able to utilize
> SQL Server without much learning curve. I bet there are people out there
> that have programmed in .NET but have NEVER written a SQL SELECT statement.
> That is scary!!

I don't see why. Not every application needs a database. I bet there
are people out there who've programmed in SQL but have never written a
C# app - but I don't see that as a problem either, do you?

> The ability to requery data on the client is an essential tool for every
> developer, unless you never save your data. They do give you dataviews, but
> you cannot do a DISTINCT listing on those. They only give you the ability
> to order data (SET ORDER TO), filter data (SET FILTER TO), and some
> others...
>
> HEY M$ - WE NEED TO MANIPULATE DATA ON OTHER PLACES BEYOND STORED
> PROCEDURES!!!!!!! THAT IS KEY TO OUR JOB!!!!!

I agree that the filtering is too limited, but rather than requiring a
full ANSI SQL engine built into .NET, I'd prefer to be able to set up
views based on delegate callbacks. That would make it much more
flexible, with much less work on Microsoft's part and much less extra
code. (Think of the Compact Framework, where this functionality would
still be very useful, but space is at a premium.)

Admittedly I haven't looked at ADO.NET 2.0 yet - maybe this
functionality is already coming...

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

We can only hope...

> > This will allow other developers to learn ANSI syntax and be able to
utilize
> > SQL Server without much learning curve. I bet there are people out
there
> > that have programmed in .NET but have NEVER written a SQL SELECT
statement.
> > That is scary!!
>
> I don't see why. Not every application needs a database. I bet there
> are people out there who've programmed in SQL but have never written a
> C# app - but I don't see that as a problem either, do you?

I agree with you. I should have made myself more clear. But, I did say in
my original post

> > The ability to requery data on the client is an essential tool for every
> > developer, unless you never save your data.

I said this - but I would still like some other tools for data manipulation.
The type of manipulation you want to do may not be the same manipulation
that I want to do. The only way to do this is give us tools that do what we
need to do. I would think a SQL Engine would be an excellent comprimise.
This can be done through an inclusion.

If you do not need it, then do not use it. There is a lot of functionality
that i never use but I get it - I am sure the same is true for you...

Thanks for the post...

"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Ty Salistean <(E-Mail Removed)> wrote:
> > Why can't M$ allow .NET developers to run ANSI standard SQL queries on
> > ADO.NET datatables/datasets (SELECT, INSERT, UPDATE, DELETE)?
>
> Well, for a start that would require a full SQL engine built into .NET.
>
> > This will allow other developers to learn ANSI syntax and be able to
utilize
> > SQL Server without much learning curve. I bet there are people out
there
> > that have programmed in .NET but have NEVER written a SQL SELECT
statement.
> > That is scary!!
>
> I don't see why. Not every application needs a database. I bet there
> are people out there who've programmed in SQL but have never written a
> C# app - but I don't see that as a problem either, do you?
>
> > The ability to requery data on the client is an essential tool for every
> > developer, unless you never save your data. They do give you dataviews,
but
> > you cannot do a DISTINCT listing on those. They only give you the
ability
> > to order data (SET ORDER TO), filter data (SET FILTER TO), and some
> > others...
> >
> > HEY M$ - WE NEED TO MANIPULATE DATA ON OTHER PLACES BEYOND STORED
> > PROCEDURES!!!!!!! THAT IS KEY TO OUR JOB!!!!!
>
> I agree that the filtering is too limited, but rather than requiring a
> full ANSI SQL engine built into .NET, I'd prefer to be able to set up
> views based on delegate callbacks. That would make it much more
> flexible, with much less work on Microsoft's part and much less extra
> code. (Think of the Compact Framework, where this functionality would
> still be very useful, but space is at a premium.)
>
> Admittedly I haven't looked at ADO.NET 2.0 yet - maybe this
> functionality is already coming...
>
> --
> Jon Skeet - <(E-Mail Removed)>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too

Ty Salistean <(E-Mail Removed)> wrote:
> > I don't see why. Not every application needs a database. I bet there
> > are people out there who've programmed in SQL but have never written a
> > C# app - but I don't see that as a problem either, do you?
>
> I agree with you. I should have made myself more clear. But, I did say in
> my original post
>
> > > The ability to requery data on the client is an essential tool for every
> > > developer, unless you never save your data.

Well yes, but there are also plenty of apps which save data but don't
need to use a database. Most word processors don't have databases in
them, for example...

> I said this - but I would still like some other tools for data manipulation.
> The type of manipulation you want to do may not be the same manipulation
> that I want to do. The only way to do this is give us tools that do what we
> need to do. I would think a SQL Engine would be an excellent comprimise.
> This can be done through an inclusion.

How is a SQL engine a compromise? It's a *lot* of work, and in many
cases still wouldn't give as much ease and flexibility (and compile-
time type safety) as a callback-based filter.

> If you do not need it, then do not use it. There is a lot of functionality
> that i never use but I get it - I am sure the same is true for you...

Yes, but the suggestion I made would give a lot of flexibility for a
vast amount less cost in terms of both work and framework size.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

I will say that by using an ANSI standard for re-filtering data is still a
better option. Someone coming to .NET from and SQL compliant language would
be able to understand the syntax alot better. What other manipulation tool
would accomodate everyone?

> How is a SQL engine a compromise? It's a *lot* of work, and in many
> cases still wouldn't give as much ease and flexibility (and compile-
> time type safety) as a callback-based filter.

I am sure data technologies such as RDO, DAO, and ADO were not easy to
accomplish. Why did they suck? Data manipulation, navigation, etc...

> Well yes, but there are also plenty of apps which save data but don't
> need to use a database. Most word processors don't have databases in
> them, for example...

We can discuss this all day. Then do NOT include the System.Data.SQL.dll
(or whatever) with your app.

At least we can agree that if you are working with data, it would be nice to
have some other way to process that data easily. To be completely honest, I
do not care how they do it...simply realize the need is there...


"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Ty Salistean <(E-Mail Removed)> wrote:
> > > I don't see why. Not every application needs a database. I bet there
> > > are people out there who've programmed in SQL but have never written a
> > > C# app - but I don't see that as a problem either, do you?
> >
> > I agree with you. I should have made myself more clear. But, I did say
in
> > my original post
> >
> > > > The ability to requery data on the client is an essential tool for
every
> > > > developer, unless you never save your data.
>
> Well yes, but there are also plenty of apps which save data but don't
> need to use a database. Most word processors don't have databases in
> them, for example...
>
> > I said this - but I would still like some other tools for data
manipulation.
> > The type of manipulation you want to do may not be the same manipulation
> > that I want to do. The only way to do this is give us tools that do
what we
> > need to do. I would think a SQL Engine would be an excellent
comprimise.
> > This can be done through an inclusion.
>
> How is a SQL engine a compromise? It's a *lot* of work, and in many
> cases still wouldn't give as much ease and flexibility (and compile-
> time type safety) as a callback-based filter.
>
> > If you do not need it, then do not use it. There is a lot of
functionality
> > that i never use but I get it - I am sure the same is true for you...
>
> Yes, but the suggestion I made would give a lot of flexibility for a
> vast amount less cost in terms of both work and framework size.
>
> --
> Jon Skeet - <(E-Mail Removed)>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too

Ty Salistean <(E-Mail Removed)> wrote:
> I will say that by using an ANSI standard for re-filtering data is still a
> better option. Someone coming to .NET from and SQL compliant language would
> be able to understand the syntax alot better.

And someone who comes from a non-SQL background will find it harder to
use. There are swings and roundabouts, but you've got to admit that it
would take a *lot* more effort to write a full SQL engine than to
include callbacks.

Bearing in mind that MS doesn't have unlimited resources, I suspect
that there are if callbacks were in place to cope with 99% of filters,
those resources would be better spent elsewhere.

Heck, with sufficiently powerful callbacks in place *you* could write
your own SQL engine if it's that important to you. Or another 3rd party
could, and charge for it.

> What other manipulation tool would accomodate everyone?

SQL wouldn't accommodate everyone to start with. There are many things
which are hard to express in SQL but easy to express programmatically.
Consider a data table which doesn't just store strings, numbers etc,
but rich objects - how would you access those in ANSI SQL?

> > How is a SQL engine a compromise? It's a *lot* of work, and in many
> > cases still wouldn't give as much ease and flexibility (and compile-
> > time type safety) as a callback-based filter.
>
> I am sure data technologies such as RDO, DAO, and ADO were not easy to
> accomplish. Why did they suck? Data manipulation, navigation, etc...

I don't see your point. I was offering a much more straightforward
solution to the problem - one which would give a similar amount of
power, making things easier in some cases and harder in others. It
would not only be easier to implement, but much cheaper in terms of
space, so it could be available on space-limited devices.

> > Well yes, but there are also plenty of apps which save data but don't
> > need to use a database. Most word processors don't have databases in
> > them, for example...
>
> We can discuss this all day. Then do NOT include the System.Data.SQL.dll
> (or whatever) with your app.

Sure. I'm just disputing your implication that it was shocking that
people might be using .NET without knowing SQL. You seemed to be under
the impression that all apps *should* be using databases. That's just
not the case.

> At least we can agree that if you are working with data, it would be nice to
> have some other way to process that data easily. To be completely honest, I
> do not care how they do it...simply realize the need is there...

Yup.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

> > > Well yes, but there are also plenty of apps which save data but don't
> > > need to use a database. Most word processors don't have databases in
> > > them, for example...

I assume people read things in the context of the subject. Since this post
originally had to deal with DATA ACCESS lets talk in terms of DATA ACCESS.
So if you do not access data, then please do not respond.

It would be nice if we could get an ANSI standard SQL compliant way to
manipulate data, for those people that need to manipulate data in
datatables/datasets.

> > > How is a SQL engine a compromise? It's a *lot* of work, and in many
> > > cases still wouldn't give as much ease and flexibility (and compile-
> > > time type safety) as a callback-based filter.
> >
> > I am sure data technologies such as RDO, DAO, and ADO were not easy to
> > accomplish. Why did they suck? Data manipulation, navigation, etc...
>
> I don't see your point. I was offering a much more straightforward
> solution to the problem - one which would give a similar amount of
> power, making things easier in some cases and harder in others. It
> would not only be easier to implement, but much cheaper in terms of
> space, so it could be available on space-limited devices.

My point was that RDO, DAO, and ADO took *alot* of resources and they still
suck. What was the main problem with them? Data manipulation, navigation,
etc... I think it is time to address the real issues...

> SQL wouldn't accommodate everyone to start with. There are many things
> which are hard to express in SQL but easy to express programmatically.
> Consider a data table which doesn't just store strings, numbers etc,
> but rich objects - how would you access those in ANSI SQL?

The same way SQL Server and every other SQL compliant database handles it.

Using the ANSI standard is a better soution, to me. I am sick of buying and
learning 3rd party tools. I want enterprise tools out of the box. I can
choose to use those tools or not.

It would take more time to get a SQL engine plugged into .NET than your
solution. But then things, like adding a row(s) to a datatable would not be
so cryptic or updating a row(s) would be auto-magical. How cool would that
be?

I am curious if anyone else has any input. Please post.

"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Ty Salistean <(E-Mail Removed)> wrote:
> > I will say that by using an ANSI standard for re-filtering data is still
a
> > better option. Someone coming to .NET from and SQL compliant language
would
> > be able to understand the syntax alot better.
>
> And someone who comes from a non-SQL background will find it harder to
> use. There are swings and roundabouts, but you've got to admit that it
> would take a *lot* more effort to write a full SQL engine than to
> include callbacks.
>
> Bearing in mind that MS doesn't have unlimited resources, I suspect
> that there are if callbacks were in place to cope with 99% of filters,
> those resources would be better spent elsewhere.
>
> Heck, with sufficiently powerful callbacks in place *you* could write
> your own SQL engine if it's that important to you. Or another 3rd party
> could, and charge for it.
>
> > What other manipulation tool would accomodate everyone?
>
> SQL wouldn't accommodate everyone to start with. There are many things
> which are hard to express in SQL but easy to express programmatically.
> Consider a data table which doesn't just store strings, numbers etc,
> but rich objects - how would you access those in ANSI SQL?
>
> > > How is a SQL engine a compromise? It's a *lot* of work, and in many
> > > cases still wouldn't give as much ease and flexibility (and compile-
> > > time type safety) as a callback-based filter.
> >
> > I am sure data technologies such as RDO, DAO, and ADO were not easy to
> > accomplish. Why did they suck? Data manipulation, navigation, etc...
>
> I don't see your point. I was offering a much more straightforward
> solution to the problem - one which would give a similar amount of
> power, making things easier in some cases and harder in others. It
> would not only be easier to implement, but much cheaper in terms of
> space, so it could be available on space-limited devices.
>
> > > Well yes, but there are also plenty of apps which save data but don't
> > > need to use a database. Most word processors don't have databases in
> > > them, for example...
> >
> > We can discuss this all day. Then do NOT include the
System.Data.SQL.dll
> > (or whatever) with your app.
>
> Sure. I'm just disputing your implication that it was shocking that
> people might be using .NET without knowing SQL. You seemed to be under
> the impression that all apps *should* be using databases. That's just
> not the case.
>
> > At least we can agree that if you are working with data, it would be
nice to
> > have some other way to process that data easily. To be completely
honest, I
> > do not care how they do it...simply realize the need is there...
>
> Yup.
>
> --
> Jon Skeet - <(E-Mail Removed)>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too

Well, someone else has tought about it:
http://www.queryadataset.com/

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF


"Ty Salistean" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Why can't M$ allow .NET developers to run ANSI standard SQL queries on
> ADO.NET datatables/datasets (SELECT, INSERT, UPDATE, DELETE)?
>
> This will allow other developers to learn ANSI syntax and be able to
> utilize
> SQL Server without much learning curve. I bet there are people out there
> that have programmed in .NET but have NEVER written a SQL SELECT
> statement.
> That is scary!!
>
> The ability to requery data on the client is an essential tool for every
> developer, unless you never save your data. They do give you dataviews,
> but
> you cannot do a DISTINCT listing on those. They only give you the ability
> to order data (SET ORDER TO), filter data (SET FILTER TO), and some
> others...
>
> HEY M$ - WE NEED TO MANIPULATE DATA ON OTHER PLACES BEYOND STORED
> PROCEDURES!!!!!!! THAT IS KEY TO OUR JOB!!!!!
>
>

Unbelievable!!! Excellent post. That is exactly what I was looking for.

Looks like that person has it only in beta and only handles SELECT's. Maybe
M$ can buy this product and put it in the next VS.NET. Thanks for the
info...

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:(E-Mail Removed)...
> Well, someone else has tought about it:
> http://www.queryadataset.com/
>
> --
> Sylvain Lafontaine, ing.
> MVP - Technologies Virtual-PC
> E-mail: http://cerbermail.com/?QugbLEWINF
>
>
> "Ty Salistean" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
> > Why can't M$ allow .NET developers to run ANSI standard SQL queries on
> > ADO.NET datatables/datasets (SELECT, INSERT, UPDATE, DELETE)?
> >
> > This will allow other developers to learn ANSI syntax and be able to
> > utilize
> > SQL Server without much learning curve. I bet there are people out
there
> > that have programmed in .NET but have NEVER written a SQL SELECT
> > statement.
> > That is scary!!
> >
> > The ability to requery data on the client is an essential tool for every
> > developer, unless you never save your data. They do give you dataviews,
> > but
> > you cannot do a DISTINCT listing on those. They only give you the
ability
> > to order data (SET ORDER TO), filter data (SET FILTER TO), and some
> > others...
> >
> > HEY M$ - WE NEED TO MANIPULATE DATA ON OTHER PLACES BEYOND STORED
> > PROCEDURES!!!!!!! THAT IS KEY TO OUR JOB!!!!!
> >
> >
>
>