Data Access...

  • Thread starter Thread starter Ty Salistean
  • Start date Start date
T

Ty Salistean

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 said:
Why can't M$ allow .NET developers to run ANSI standard SQL queries on
ADO.NET datatables/datasets (SELECT, INSERT, UPDATE, DELETE)?
Click to expand...

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!!
Click to expand...

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!!!!!
Click to expand...

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...
 
We can only hope...
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?
Click to expand...

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

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...
 
Ty Salistean said:
I agree with you. I should have made myself more clear. But, I did say in
my original post
Click to expand...

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.
Click to expand...

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...
Click to expand...

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.
 
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.
Click to expand...

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...
Click to expand...

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...
 
Ty Salistean said:
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.
Click to expand...

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?
Click to expand...

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?
I am sure data technologies such as RDO, DAO, and ADO were not easy to
accomplish. Why did they suck? Data manipulation, navigation, etc...
Click to expand...

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.
We can discuss this all day. Then do NOT include the System.Data.SQL.dll
(or whatever) with your app.
Click to expand...

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...
Click to expand...

Yup.
 
Well yes, but there are also plenty of apps which save data but don't
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.
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.
Click to expand...

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?
Click to expand...

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.
 
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...
 
Ty Salistean said:
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.
Click to expand...

Your original post didn't qualify it at all though. It expressed
surprise at the fact that people have programmed in .NET without
knowing SQL - not .NET which access databases, just .NET.

Have another look at your original post and see whether you don't think
it's a bit overdone.
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.
Click to expand...

I agree it's a nice to have. I just disagree that it's vital.
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...
Click to expand...

And callbacks would address many of those issues, IMO, in a far cheaper
way.
The same way SQL Server and every other SQL compliant database handles it.
Click to expand...

I thought SQL wasn't designed around a rich object model though. How do
you call a method on an object in SQL (rather than a function)? How do
you get at the properties of an object? Does SQL even mention objects,
rather than specific predefined datatypes?
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.
Click to expand...

What difference does it make whether it's 3rd party or from MS? Given
that you've said it should be optional anyway, what does it matter who
provides it?
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?
Click to expand...

I don't find adding rows to be cryptic anyway, personally...
 
Jon said:
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.
Click to expand...

Though they already have one: the JET engine. THough MS knows that an
in-memory DB engine is not what you want: it will encourage developers
to keep more data in memory which makes the data more stale over time
and more error prone due to the fact it gets out-of-sync.

FB

--
 
Thanks for the post.

Jon Skeet said:
Your original post didn't qualify it at all though. It expressed
surprise at the fact that people have programmed in .NET without
knowing SQL - not .NET which access databases, just .NET.

Have another look at your original post and see whether you don't think
it's a bit overdone.


I agree it's a nice to have. I just disagree that it's vital.


And callbacks would address many of those issues, IMO, in a far cheaper
way.
it.

I thought SQL wasn't designed around a rich object model though. How do
you call a method on an object in SQL (rather than a function)? How do
you get at the properties of an object? Does SQL even mention objects,
rather than specific predefined datatypes?


What difference does it make whether it's 3rd party or from MS? Given
that you've said it should be optional anyway, what does it matter who
provides it?


I don't find adding rows to be cryptic anyway, personally...
Click to expand...
 
You might be interested in the assembly I've been working on at http://www.queryadataset.com. Besides DISTINCT, it lets you perform complex SQL SELECT statements including UNION, JOINS, GROUP BY, HAVING, ORDER BY, sub-queries, etc against the tables in a dataset.

I choosen not to support INSERT, UPDATE and DELETE because without transactions, these may not be useful. While basic transaction support is available with ADO.NET, it doesn't work well in a highly concurrent situation. This is really a weakness of ADO.NET.

**********************************************************************
Sent via Fuzzy Software @ http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...
 
Back
Top