Board index » delphi » Re: Delphi 8 and ado.net

Re: Delphi 8 and ado.net


2004-03-01 11:21:12 AM
delphi227
"Nick Hodges (TeamB)" <XXXX@XXXXX.COM>writes
Quote
>Well, I don't know what the equivalent to DataRelation classes are
>for the CDS but you might shed some light here.
Nested datasets. Been there long before anyone at MS thought about it,
I daresay.
That has nothing to do with what I asked. Nested datasets are datatables.
Data relations don't exist in the CDS as far as I can tell.
Quote
>How would I set the CDS to have 4 tables (1 master, 2 details and 1
>sub detail) and have rows automatically deleted or updated when I
>change a master (cascade updates, no code)?
With nested datasets.
And how do I prevent the master from being deleted if the details exist?
[..]
Quote
Without writing code? I confess I don't know if a CDS will do that.
Yes, because there's no concept of data relation which is the big thing
about ADO.Net datasets that is often underestimated by poor comparisons
between the CDS and the ADO.Net dataset.
[..]
Quote
Post/ApplyUpdates allows you to control exactly how things are managed
within the CDS and the actual database. You can look at and modify the
Delta all you want -- via the Delta property.
That gives me an OleVariant, not an object. How do I browse through the
changes and manipulate them before they are sent to the middle tier?
Basically where are the diffgrams?
[..]
Quote
No, you are not correct. Any nested dataset can be easily extracted
and manipulated.
With how much and what type of code?
Quote
>Ah, finally, how would I
>perform a simple XPath query on my data?
Export any of the tables as XML, and do it that way.
Yes, but my question was can you show me the code to do that?
How much code is required? Was just a curiosity. I am sure that if all that
the ADO .Net dataset offers is doable in the CDS, it would take us the same
amount of code.
 
 

Re: Delphi 8 and ado.net

Alessandro Federici [RemObjects Software] writes:
Quote
That has nothing to do with what I asked. Nested datasets are
datatables. Data relations don't exist in the CDS as far as I can
tell.
A nested dataset almost always is a datarelation, right?
Quote
And how do I prevent the master from being deleted if the details
exist?
OnBeforeDelete, I suppose.
Quote
Yes, because there's no concept of data relation which is the big
thing about ADO.Net datasets that is often underestimated by poor
comparisons between the CDS and the ADO.Net dataset.
I don't agree totally -- CDS can provide the functionality, just not
without doing some coding.
Quote
That gives me an OleVariant, not an object. How do I browse through
the changes and manipulate them before they are sent to the middle
tier? Basically where are the diffgrams?
You assign the Delta to another CDS, and browse/modify/delete as
desired, and assign it back.
Quote
With how much and what type of code?
Something like
MyNewCDS.Data := MyNestedCDS.Data;
Quote
Yes, but my question was can you show me the code to do that?
How much code is required? Was just a curiosity. I am sure that if
all that the ADO .Net dataset offers is doable in the CDS, it would
take us the same amount of code.
I'll agree that my statement "does nothing..." was an exaggeration. I
am a touch surprised you aren't more familiar with CDS's.
--
Nick Hodges -- TeamB
Lemanix Corporation
Read my Delphi Blog -- www.lemanix.com/nick/
 

Re: Delphi 8 and ado.net

"Nick Hodges (TeamB)" <XXXX@XXXXX.COM>writes
[..]
Quote
A nested dataset almost always is a datarelation, right?
No. A data relation could exist between datasets that are not nested.
Quote
>And how do I prevent the master from being deleted if the details
>exist?
OnBeforeDelete, I suppose.
Code is not allowed ;-)))
[..]
Quote
I don't agree totally -- CDS can provide the functionality, just not
without doing some coding.
Well, then everything is possible even with a TList!
Nick, the point is that the three objects (CDS, ADO Recordset and ADO.Net
dataset) have a lot of similarities but the first two don't allow you to do
everything the 3rd does without having to put manual code in. that is the
whole point of adopting new tools, isn't i? To find a way to do the things
you always do better and with less efforts.
Now, having said that, this doesn't mean that the ADO.Net dataset has
*everything* the CDS has. Field constraints are not present for instance
(unless my memory fails me) and I don't think cloned cusrors are in either.
They are similar in scope but very different beasts underneat and in the way
you use them.
Quote
>That gives me an OleVariant, not an object. How do I browse through
>the changes and manipulate them before they are sent to the middle
>tier? Basically where are the diffgrams?
You assign the Delta to another CDS, and browse/modify/delete as
desired, and assign it back.
That I didn't know, but I am still not getting what I was hoping to get:
typed objects.
It's very different and I have to do a lot manual coding to perform what the
diffgrams methods offer.
People might make people think you'd have to go trough the same painful code
to access delta changes programmatically ;-))
[..]
Quote
I'll agree that my statement "does nothing..." was an exaggeration. I
am a touch surprised you aren't more familiar with CDS's.
I was being sarcastic in all my questions but I have to admit I didn't know
I could browse the delta the way you showed me. The point I made is that
yes, you could ultimately do many (but not all, careful) of the things the
ADO.Net dataset does but there's so much more that is done in a quicker and
more structured way that (IMHO) hinting they work the same way or do the
same things is missleading to say the least.
Borland made a great component. MS made a new one and improved on both CDS
and ADO Recordsets: now it is time for Borland to create a new one that is
better than all these (and there's plenty of space to improve on the ADo.Net
dataset) ;-)))
 

Re: Delphi 8 and ado.net

Alessandro Federici [RemObjects Software] writes:
Quote
No. A data relation could exist between datasets that are not nested.
Okay -- I don't see why you can not do that in the VCL, i.e. between any
two VCL datasets.
Quote
Code is not allowed ;-)))
Why not? I take your point, but I never said that no code was needed.
In addition, I don't claim an expertise here, and it may very well be
possible to do this without code.
Quote
Nick, the point is that the three objects (CDS, ADO Recordset and
ADO.Net dataset) have a lot of similarities but the first two don't
allow you to do everything the 3rd does without having to put manual
code in.
Okay, why didn't you make that point earlier? I don't disagree with it.
Quote
That's the
whole point of adopting new tools, isn't i? To find a way to do the
things you always do better and with less efforts.
Why would I disagree? You seem to be arguing with someone over
something, but it is not me, and it is over a point you haven't clearly
articulated.
Quote
Now, having said that, this doesn't mean that the ADO.Net dataset has
*everything* the CDS has. Field constraints are not present for
instance (unless my memory fails me) and I don't think cloned cusrors
are in either. They are similar in scope but very different beasts
underneat and in the way you use them.
TFields are also sorely missing, IMO. In addition, as far as I can
tell, there is no concept of a cursor at all. it is easy to iterate,
but impossible to tell where you are in the dataset /without/ using UI
elements. that is really not good, in my view.
Quote
People might make people think you'd have to go trough the same
painful code to access delta changes programmatically ;-))
It's not painful at all. it is quite easy.
Quote
Borland made a great component. MS made a new one and improved on
both CDS and ADO Recordsets: now it is time for Borland to create a
new one that is better than all these (and there's plenty of space to
improve on the ADo.Net dataset) ;-)))
I am hoping for a bdpDataset that adds TField objects so you can manage
the data in a table way more easily that Table[i].Row[j], etc.
--
Nick Hodges -- TeamB
Lemanix Corporation
Read my Delphi Blog -- www.lemanix.com/nick/
 

Re: Delphi 8 and ado.net

"Nick Hodges (TeamB)" <XXXX@XXXXX.COM>writes
Quote
Okay -- I don't see why you can not do that in the VCL, i.e. between any
two VCL datasets.
Because the whole point of using nested datasets in the CSS or using those
features in the ADO.Net one is exactly to encapsulate everything in one
object which contains the relationships.
It's basically like having an in memory database with referential
constraints, data integrity and so on. But without code. that is exactly the
beauty of the ADO.Net dataset.
Quote
Why not?
Because then I could say I can do everything the CDS does by creating my own
objects or using a list of tlists. Would that be a meaningful comparison?
Quote
I take your point, but I never said that no code was needed.
I know that but by following the logic that you can do in the CDS (with
code) what you can do in ADO.Net datasets would void the point of buying any
Delphi after 2 for Win32. I could do anything I do today with Delphi 7 in D2. Is
it worth doing it?
Your initial sentence sounds very much like "ADO.Net doesn't do anything
more than what the CDS did" which is, as we saw, not the case.
Quote
Okay, why didn't you make that point earlier? I don't disagree with it.
Yes, and I am looking at closing this thread actually.
We agreed on the fact the ADO.Net has more features.
[..]
Quote
TFields are also sorely missing, IMO.
I don't understant this one. The ADO.net has a concept of row and data
columns which are the fields
msdn.microsoft.com/library/default.asp
Quote
In addition, as far as I can
tell, there is no concept of a cursor at all.
Correct and that is quite an iprovement and really adds a lot of flexibility
to how you write applications (the thread example I made before a simple
one).
Quote
It's easy to iterate,
but impossible to tell where you are in the dataset /without/ using UI
elements. that is really not good, in my view.
You always know where you are since you have a pointer yourself (integer
variable for instance)!
[..]
Quote
I am hoping for a bdpDataset that adds TField objects so you can manage
the data in a table way more easily that Table[i].Row[j], etc.
See above. I am not following you on this one.
You have data columns and strongly typed datasets. What else could you need?
 

Re: Delphi 8 and ado.net

In borland.public.delphi.non-technical, "Alessandro Federici [RemObjects
Software]" <XXXX@XXXXX.COM>writes
<4042a581$XXXX@XXXXX.COM>...
Quote
The dataset is based on the concept of
cursor while ADO.Net datasets are more similar to an XML document in which
you basically have arrays of arrays of elements.
To me this is a very interesting difference. I recently had a need to fit
several different tables into a portable format. I used CDS's but had to use
a separate CDS for each table and then zip them all into a single file*. A
lot of extra grunt work because each CDS can hold only one table. Ugh. Yet
another thing that
would be better in .NET.
*If I had the expensive version of Delphi 7 I probably could have conveniently
created an XML file for this, I
guess.
--
***Free Your Mind***
 

Re: Delphi 8 and ado.net

Captain Jake writes:
Quote
A
lot of extra grunt work because each CDS can hold only one table.
Not true -- check out nested datasets. A CDS can easily hold three
different tables.
--
Nick Hodges -- TeamB
Lemanix Corporation
Read my Delphi Blog -- www.lemanix.com/nick/
 

Re: Delphi 8 and ado.net

"Nick Hodges (TeamB)" <XXXX@XXXXX.COM>writes
[..]
Quote
Not really. that is taking things to an unnecessary extreme, I think.
Having to write /some/ code within the events of a CDS isn't that big
of a deal.
It was an extreme example but keep adding a lot of these small things and
you end up with a lot extra code (this is a general statement that applies
to some things of .Net as well).
[..]
Quote
And which I have already said was hyperbole, though not entirely
inaccurate.
Right and I am glad we got there with only few posts <G>
Quote
There is nothing, of course, that VCL/TDataset won't do
that ADO.NET will, but it might take a bit of work or code, or it may
not be encapsulated as much as you might like.
Right, like with an ADO Recordset (to make less of an hyperbole).
Quote
I'd agree that ADO.NET has some features that CDS doesn't have, and
that CDS/TDataset has some that ADO.NET doesn't have.
Agreed.
Quote
>The ADO.net has a concept of row and data
>columns which are the fields
They don't represent the data, just the metadata for the columns, as
far as I can tell.
I see what you mean. Well, different approach. The values are elsewhere.
Quote
Well, I disagree.
That makes 2 of us then ;-))
Quote
Try this -- try to find out the last name of the person with EMPNO = 94
[..]
Use DataTable.Select('EMPNO=94") which returns you a list of datarows that
don't affect your original data like filters do.
Quote
Nice TField objects to represent each column and it is data.
Which was one of the big problems I had when making DA: apples and oranges
(visual attributes and field/business ones) and in the end I had to stick to
the convention of Delphi's VCL...
Anyhow, different styles.
 

Re: Delphi 8 and ado.net

Captain Jake writes:
Quote
That is such an excellent anecdote. It really captures the number one problem
in software development:
preconceptions and fear of change.
Or "preconceptions" and "fear of change" could instead be:
"investment in current skills" and "preservation of productivity".
It's hard to know when to jump.
I went through 6-months to a year of productivity hits when I switched
to Delphi, before the tide turned.
And I am still just starting to get decent at the things all the
(so-called) experts around here now find passe: client-server
applications, object-oriented programming for example.
I understand, some are in a position to be trailblazers by nature of
their work, and others must consider whether they want to gamble their
paychecks on the productivity of the current ways against a promise of
some new trend, which could be a trend or could be a fad.
For web-based programming, I am seriously wanting to try Delphi 8. For
client (Windows) programming, I will just wait until there's a payoff in
the here an now and not merely "this is the wave of the future".
--
"The system is less energetic when domains of opposite direction
alternate." - Dr. Memory
 

Re: Delphi 8 and ado.net

Alessandro Federici [RemObjects Software] writes:
Quote
It was an extreme example but keep adding a lot of these small things
and you end up with a lot extra code (this is a general statement
that applies to some things of .Net as well).
Well, code isn't /totally/ evil. ;-)
Quote
Use DataTable.Select('EMPNO=94") which returns you a list of datarows
that don't affect your original data like filters do.
I'll check out Select...
--
Nick Hodges -- TeamB
Lemanix Corporation
Read my Delphi Blog -- www.lemanix.com/nick/
 

Re: Delphi 8 and ado.net

Nick Hodges (TeamB) writes:
Quote
What are the advantages over using Clientdatasets?
To be clear, functionally, everything you can do with a DataSet you can
do with a ClientDataSet. it is not a question of technical capability.
I personally find the the DataSet appraoch far more elegant than I do
the ClientDataSet. DataSet is part of and works well with the FCL, It
is a braindead effort to load all my Lookup Tables in one swoop, cache
them for quick retrieval in an ASP.NET application for retrieveal upon
each page request.
ie: The following can retrieve all 24 of my lookup tables and puts them
in the the Cache:
var
sqlcn: SqlConnection;
sqlDa: SqlDataAdapter;
Ds: DataSet;
begin
sqlcn := SqlConnection.Create(c_cnstr);
sqlDA := SqlDataAdapter.Create('SELECT * from LU_1; SELECT * FROM
LU_2 ...', sqlcn);
Ds := DataSet.Create;
sqlDA.Fill(Ds);
Cache['dsLookups'] := Ds;
sqlcn.Close;
end;
Now to retrieve one of the lookup tables to populate a drop down list
on my web page is a one-liner
SomeLookup.DataSource :=
DataSet(Cache['dsLookups']).Tables['SpecificLookup'];
At design time I'd have set up the Data and Value properties for
the lookup.
It simply works natually. Can I do the same with TClientDataSet - of
course its less elegant requires more code and the result does't work
well with the databinding controls (unless I stick to borland's
controls).
I think it is good that folks discuss such differences here, I think it
would be better to illustrate code for both techniques as I feel this
would good for developers. I am putting together yet another Delphi/.NET
web site that will contain my book examples and I just got the idea to
post the following three items for each of my examples;
The FCL Delphi way
The VCL Delphi way
The C# way
These won't be limited to by book examples so I am interested in any
ideas.
--- x
------------------------------------
Xapware Technologies Inc.
Manage your projects with
Active! Focus - Get More Done!
www.xapware.com
 

Re: Delphi 8 and ado.net

Xavier Pacheco (Xapware) writes:
Quote
elegant
This has /got/ to be the most overused word in the business today. ;-)
Good post, thanks.
For the record, there are things about ADO.NET that I don't like, but I
freely admit that I haven't quite got past the "thinking in Delphi/VCL"
way of doing things into the "Thinking in ADO.NET" way of doing things.
--
Nick Hodges -- TeamB
Lemanix Corporation
Read my Delphi Blog -- www.lemanix.com/nick/
 

Re: Delphi 8 and ado.net

"Alessandro Federici [RemObjects Software]" <XXXX@XXXXX.COM>
writes news:XXXX@XXXXX.COM...
Quote
Not really since you still have the option to go TField alike if you want
to.
You've both options rather than just one.
Do you see any advantage to using TFields for ADO.NET development?
 

Re: Delphi 8 and ado.net

Nick Hodges (TeamB) writes:
Quote
Xavier Pacheco (Xapware) writes:

>elegant

This has got to be the most overused word in the business today. ;-)
I'm trying to *leverage* it as much as I can! :)
Quote
>I haven't quite got past the "thinking in
Delphi/VCL" way of doing things into the "Thinking in ADO.NET" way of
doing things. <<
Had I not written the book, Nick, I would still be thinking that way.
That's why my advice for anybody wondering about all this is to try it
by actually writing several good sized applications that cover many
facets of the framework. Then, decide.
The VCL is still an awesome framework and I am looking forward to many
many years of using it.
-- x
------------------------------------
Xapware Technologies Inc.
Manage your projects with
Active! Focus - Get More Done!
www.xapware.com
 

Re: Delphi 8 and ado.net

Xavier Pacheco (Xapware) writes:
Quote
I'm trying to leverage it as much as I can! :)
It is a new *paradigm* after all.
Quote
Had I not written the book, Nick, I would still be thinking that way.
That's why my advice for anybody wondering about all this is to try it
by actually writing several good sized applications that cover many
facets of the framework. Then, decide.
I'm trying to move our website over to ASP.NET/ADO.NET, and it is slow
going. My brain is likely the biggest obstacle.
--
Nick Hodges -- TeamB
Lemanix Corporation
Read my Delphi Blog -- www.lemanix.com/nick/