Access maybe, Sql no

I would have preferred Access rather than Access Hollywood.

Good luck,

"'69 Camaro" AM wrote in
message ...
I'm willing to listen and learn where I've taken a wrong turn
understanding databases.
The floor is yours.

Thank you. I recommend you start on the following Web pages:


http://www.amazon.com/Miss-Manners-C...8172297&sr=1-1


http://www.amazon.com/Manners-Excruc...8172297&sr=1-1

The books can be read quickly, but it takes about two to five years of
daily
practice for the concepts to sink in. Go ahead and get started. I'll
wait.

HTH.
Gunny


"Steve Dassin" rac4sqlnospam@net wrote in message
...
I'm willing to listen and learn where I've taken a wrong turn
understanding databases.
The floor is yours.

"'69 Camaro" AM wrote
in
message ...
Sir, please share with us the name of the school you are currently
attending
so that no one else has the misfortune of following in your footsteps
and
suffering the consequences of being taught that it is ever acceptable
to
conduct oneself in an unprofessional, immature manner by calling
someone
trying to be helpful a jackass, that it is ever acceptable to spam the
technical newsgroups, and whose education in databases leaves the
student
woefully ill-prepared to engage in a friendly discourse about
databases.

I'm trying to talk the talk as well as walk the walk.

Hold off on those walking shoes. And regarding "talking the talk"
about
databases: You should return to your school post haste and scream
bloody
murder until they refund your tuition for your database, ethics, and
philosophy courses, because you, sir, have been ripped off.

HTH.
Gunny


"Steve Dassin" rac4sqlnospam@net wrote in message
...
Hello Doug,

Doug Steele, I have a memory of that person from Access days
some time ago. I trust you are doing well.
Look, the last thing I wanted was to get into a ****ing match
with some kids. I'm sure you'll agree I would be overmatched :-).

Firstly I have *no* business connection with Alphora but a
big intellectual one. I'm simply offering an idea that I think
Access users would be receptive to. For what it's worth, here is
the result from McAfee SiteAdvisor:
http://www.siteadvisor.com/sites/alp...=safe&aff_id=0
alphora.com
Green Verdict Image
'We tested this site and didn't find any significant problems.'

And I certainly am not here to dump on Access. I recently read
stuff like this:
InfoWorld
August 08, 2007
Die Access Die!


http://weblog.infoworld.com/dbunderg...ccess_die.html


http://www.sqlservercentral.com/foru...eid=389963&p=1

Of course this debate is framed by too many nitwits. Net is a
wonderful framework. Sql server is a me too product that MySql
could easily replace. The idea of Access users going to net
and sql server is the same client-server idea thats been
around since before electricity. The whole allure of the concepts
of rapid application and what Access users refer to as the
'integration' of various components is lost on those who
think they know their way around a server database and net.
There's a fancy word for what Access tries to do, it tries to
overcome the natural impedance mismatch between a database
and a client language. The very ideas that Access users like
are in Dataphor. But these ideas are much more formalized
in a much more rigorous system. As for sql well I think I can
speak quite intelligently about it - In the entire history
of sql there has never been a 'something' else to measure it
against. Vendors and writers have forever been able to use
the terms 'relational' and sql as synonyms. Users have never
seen relational concepts that are written about. MS and Oracle
can call their systems 'relational' only because nothing existed
which users could compare. Well now there is something which
can be compared and contrasted with sql. Assumptions is the
mother of all screwups and basic assumptions about sql are
no exceptions. The idea that a language which was designed
to access 2 millions rows in a join should be the same language
for application development as a user of Access understands
the term is utterly ridiculous. It is universally assumed that
sql is a one size fits all deal. This is nonsense. And make no
mistake I am *not* taking about OO silliness or the LINQ crap
that MS is going to push. I will personally rip them to shreds
on that :-) Imagine if you will that vba was more tightly
integrated with jet. Imagine if you will that jet understood
the concept of a variable on a higher level, that it understood
different types. A 'list' type, a cursor type and finally the
most important of all, a table type. The idea of a strongly
typed database language is something users have never seen.
This is bringing the concepts of .net directly into a database
language. This is overcoming the impedance mismatch like its
never been seen before. I realize that many of these concepts
may not register with people. That is why I have practical
examples of what this stuff 'looks like' and what it can do
on my blog. I'm trying to talk the talk as well as walk the walk.
Alphora got right, I'm trying to show IT just how right.
I'm only one of a few but I still like my odds :-)

best,
steve

"Douglas J. Steele" wrote in
message
...
Sorry, Steve, but George is a consistent poster here, so I
personally
would
tend to believe him.

Perhaps you can offer some suggestion why McAfee doesn't like your
page.
(I
don't use McAfee anymore, and after George's warnings, I'm not
inclined
to
visit the site to see how my anti-virus reacts)

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)


"Steve Dassin" wrote in message
...
You can lead a horse to water but you can't make him drink.
Especially if it's a jackass

"George Nicholson" wrote in message
...
gosh, feel free to add this to your blog:

Mcafee Virus Scan went nuts on the alphora. com page. Multiple
warnings
for:

Exploit-MS06-014
Exploit-ObscuredHtml
Downloader-AYJ




"Steve Dassin" wrote in message
...
Greetings Access Users,

I'm here to sell something. An idea. Some of you may have heard
of
a
system called Dataphor from Alphora. I have been working with it
for
a
while and happen to think that an Access user would understand
the
big
picture presented by Dataphor. While I have no business
connection
with them I would be more than willing to help anyone who was
interested in exploring it. I've blogged about it quite a bit
and
presented many key concepts thru practical examples. This is not
intended to be taken as anything pejorative concerning Access.
Even
if
your just intellectually curious that is fine.
To those that are unfamiliar with Dataphor it a system that
is intended for application development much like Access.
It has a vba like language which additionally supports an sql
like
database language. But this database language is quite special
If you have questions feel free to contact me thru my blog
via comments or email.

I'd recommend turning the T.V. off and reading those Judith Martin books
instead. One isn't going to learn subjects your school's curriculum is weak
on from gossip about Hollywood celebrities on television.

HTH.
Gunny


"Steve Dassin" rac4sqlnospam@net wrote in message
...
I would have preferred Access rather than Access Hollywood.

Good luck,

"'69 Camaro" AM wrote
in
message ...
I'm willing to listen and learn where I've taken a wrong turn
understanding databases.
The floor is yours.

Thank you. I recommend you start on the following Web pages:


http://www.amazon.com/Miss-Manners-C...8172297&sr=1-1


http://www.amazon.com/Manners-Excruc...8172297&sr=1-1

The books can be read quickly, but it takes about two to five years of
daily
practice for the concepts to sink in. Go ahead and get started. I'll
wait.

HTH.
Gunny


"Steve Dassin" rac4sqlnospam@net wrote in message
...
I'm willing to listen and learn where I've taken a wrong turn
understanding databases.
The floor is yours.

"'69 Camaro" AM
wrote
in
message ...
Sir, please share with us the name of the school you are currently
attending
so that no one else has the misfortune of following in your footsteps
and
suffering the consequences of being taught that it is ever acceptable
to
conduct oneself in an unprofessional, immature manner by calling
someone
trying to be helpful a jackass, that it is ever acceptable to spam the
technical newsgroups, and whose education in databases leaves the
student
woefully ill-prepared to engage in a friendly discourse about
databases.

I'm trying to talk the talk as well as walk the walk.

Hold off on those walking shoes. And regarding "talking the talk"
about
databases: You should return to your school post haste and scream
bloody
murder until they refund your tuition for your database, ethics, and
philosophy courses, because you, sir, have been ripped off.

HTH.
Gunny


"Steve Dassin" rac4sqlnospam@net wrote in message
...
Hello Doug,

Doug Steele, I have a memory of that person from Access days
some time ago. I trust you are doing well.
Look, the last thing I wanted was to get into a ****ing match
with some kids. I'm sure you'll agree I would be overmatched :-).

Firstly I have *no* business connection with Alphora but a
big intellectual one. I'm simply offering an idea that I think
Access users would be receptive to. For what it's worth, here is
the result from McAfee SiteAdvisor:
http://www.siteadvisor.com/sites/alp...=safe&aff_id=0
alphora.com
Green Verdict Image
'We tested this site and didn't find any significant problems.'

And I certainly am not here to dump on Access. I recently read
stuff like this:
InfoWorld
August 08, 2007
Die Access Die!


http://weblog.infoworld.com/dbunderg...ccess_die.html


http://www.sqlservercentral.com/foru...eid=389963&p=1

Of course this debate is framed by too many nitwits. Net is a
wonderful framework. Sql server is a me too product that MySql
could easily replace. The idea of Access users going to net
and sql server is the same client-server idea thats been
around since before electricity. The whole allure of the concepts
of rapid application and what Access users refer to as the
'integration' of various components is lost on those who
think they know their way around a server database and net.
There's a fancy word for what Access tries to do, it tries to
overcome the natural impedance mismatch between a database
and a client language. The very ideas that Access users like
are in Dataphor. But these ideas are much more formalized
in a much more rigorous system. As for sql well I think I can
speak quite intelligently about it - In the entire history
of sql there has never been a 'something' else to measure it
against. Vendors and writers have forever been able to use
the terms 'relational' and sql as synonyms. Users have never
seen relational concepts that are written about. MS and Oracle
can call their systems 'relational' only because nothing existed
which users could compare. Well now there is something which
can be compared and contrasted with sql. Assumptions is the
mother of all screwups and basic assumptions about sql are
no exceptions. The idea that a language which was designed
to access 2 millions rows in a join should be the same language
for application development as a user of Access understands
the term is utterly ridiculous. It is universally assumed that
sql is a one size fits all deal. This is nonsense. And make no
mistake I am *not* taking about OO silliness or the LINQ crap
that MS is going to push. I will personally rip them to shreds
on that :-) Imagine if you will that vba was more tightly
integrated with jet. Imagine if you will that jet understood
the concept of a variable on a higher level, that it understood
different types. A 'list' type, a cursor type and finally the
most important of all, a table type. The idea of a strongly
typed database language is something users have never seen.
This is bringing the concepts of .net directly into a database
language. This is overcoming the impedance mismatch like its
never been seen before. I realize that many of these concepts
may not register with people. That is why I have practical
examples of what this stuff 'looks like' and what it can do
on my blog. I'm trying to talk the talk as well as walk the walk.
Alphora got right, I'm trying to show IT just how right.
I'm only one of a few but I still like my odds :-)

best,
steve

"Douglas J. Steele" wrote in
message
...
Sorry, Steve, but George is a consistent poster here, so I
personally
would
tend to believe him.

Perhaps you can offer some suggestion why McAfee doesn't like your
page.
(I
don't use McAfee anymore, and after George's warnings, I'm not
inclined
to
visit the site to see how my anti-virus reacts)

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)


"Steve Dassin" wrote in message
...
You can lead a horse to water but you can't make him drink.
Especially if it's a jackass

"George Nicholson" wrote in message
...
gosh, feel free to add this to your blog:

Mcafee Virus Scan went nuts on the alphora. com page. Multiple
warnings
for:

Exploit-MS06-014
Exploit-ObscuredHtml
Downloader-AYJ




"Steve Dassin" wrote in message
...
Greetings Access Users,

I'm here to sell something. An idea. Some of you may have heard
of
a
system called Dataphor from Alphora. I have been working with
it
for
a
while and happen to think that an Access user would understand
the
big
picture presented by Dataphor. While I have no business
connection
with them I would be more than willing to help anyone who was
interested in exploring it. I've blogged about it quite a bit
and
presented many key concepts thru practical examples. This is
not
intended to be taken as anything pejorative concerning Access.
Even
if
your just intellectually curious that is fine.
To those that are unfamiliar with Dataphor it a system that
is intended for application development much like Access.
It has a vba like language which additionally supports an sql
like
database language. But this database language is quite
special
If you have questions feel free to contact me thru my blog
via comments or email.

Well, I was hoping to have more time before posting a reply here. I didn't
got any warnings visiting your site, that is maybe good news, but, my my my,
if it wasn't about the signature (that I didn't notice in the first place),
I would have start the flame thrower in a reddish tone that would have made
J. C. flames look like fire moths. (So, keep your shields up, :-) ). And
then I noticed mentions of RAC and your signature. So, after being sure it
was very well you, not someone impersonating you, I decided to take a couple
of days in order to get some 'emotional distance toward what you wrote, in
your blog, and while I did just that, but not having time to read every
thing there, I am still left with an incomplete picture.

Some remarks, though:

- Your points are not about J. C., so even if you want to notify the reader
that you take his objections into consideration, you surely can and have to
mention it, but not as introduction to the point you develop. I refer to the
article where you ... try... to introduce the fact that a table can be a
parameter and you start the discussion by bringing one of the poorest answer
Joe Celko may have ever done in his entire life, of a mathematician (I say
that but take in account that I have a lot of respect for that guy, for the
good stuff he produced). In my opinion, I must say that for optimization of
a query plan, I still find that knowing the table, its physical structure,
its indexes, its stats, what is required (what is SELECTed), etc. can make
the optimizer find a better plan than when having a ... general ... table.
Not knowing if you SELECT DISTINCT a primary key or a secondary field, as
example, can make some difference in the lag the end user is likely to
experience, at runtime. Sure, there are cases where the optimized plan will
be very fast to obtain (so why not getting it at runtime), or where it is
irrelevant, but I cannot say that having a table, as parameter, is on my
priority list at all.

- Your writing style is (still) complex. I know mine is, also, but in this
context, my style is not relevant, I think.


- I haven't see a 'tour guide'. I am not even sure I started at the right
place! Sure, if the purpose is still to start a discussion, that can be
expected since we don't know where it will go, but there is already a lot of
material (not necessary self contained, I am afraid) and I am still not sure
about 'where' in the process of making an application you want to focus. You
are not spreading your thought about the user interface, aren't you? Ok, it
is NOT SQL, it is maybe Access, but WHAT is it? I am a little bit lost, and
have the impression that I could put my hands on great (I hope) pictures of
a movie, but still not sure if the movie is a documentary, or something
else.


- It seems you mention an interest for the framework (dot.Net) which is an
anti-SQL thing (even if they added some element of SQL in version 3.0),
imho. Gone the sub-queries, even gone the joins, just a simple
select-from-where and if you need 'join' or 'subqueries', you use the
framework objects that refer to these 'simple' statements, and use C#, or
whatever, not SQL, to carry the 'joins', but without the memory explosion
what SQL-joins do. On the other hand, from the first impression I got, it
seems you add complexity to the SQL language. So, it would be like rooting
in the wrong soil, no? Since the framework is about simple, simple SQL
statements, that is (and C# developers are ready to pay the price by writing
complex C# procedural statements, because they know C#, but not SQL, and
don't want to invest in a more complex SQL like language). I may have the
wrong idea of what you saw, though.


Yours,
Vanderghast, Access MVP




"Steve Dassin" wrote in message
...
Greetings Access Users,

I'm here to sell something. An idea. Some of you may have heard of a
system called Dataphor from Alphora. I have been working with it for a
while and happen to think that an Access user would understand the big
picture presented by Dataphor. While I have no business connection
with them I would be more than willing to help anyone who was
interested in exploring it. I've blogged about it quite a bit and
presented many key concepts thru practical examples. This is not
intended to be taken as anything pejorative concerning Access. Even if
your just intellectually curious that is fine.
To those that are unfamiliar with Dataphor it a system that
is intended for application development much like Access.
It has a vba like language which additionally supports an sql like
database language. But this database language is quite special
If you have questions feel free to contact me thru my blog
via comments or email.

Dataphor @
www.alphora.com

My blog:
www.beyondsql.blogspot.com

Hello Michel,

It's been a while
I do appreciate you taking time to explore this subject!
I hope talented and intellectually mature people like yourself
take a serious interest in this matter.

So, keep your shields up, :-)

You have my word Kirk

I decided to take a couple of days in order to get some 'emotional
distance
toward what you wrote, in your blog, and while I did just that, but not
having time to read every thing there, I am still left with an incomplete
picture.

Let me give you short overview of the entire subject.
A small group of very talented people, both conceptually and technically,
at Alphora implemented the relational model known as Tutorial D completely
specified in the book:
Databases, Types, and The Relational Model: The Third Manifesto, 3rd edition
by C. J. Date and Hugh Darwen
http://www.thethirdmanifesto.com/

This relational (non-procedural database access) language is within a Pascal
(declarative/procedural) like language. The language in toto is referred to
as
'D4' by alphora. The relational language is conceptually (radically)
different
from sql in two fundamental ways. It rests on the concept of 'type' and
'variable'. Whereas sql is absent the concept of 'type' and 'variable'
as it relates to a table. In the absence of type there is only a 'file
name',
much like there is only the value of integer 1 in the absence of the
ability to assign integer 1 to a variable. The design of the non-procedural
language is also radically different from sql. There are so many differences
with sql (conceptually, design of language, keys, use of meta-data,
constraints,
views, duplicates,procedures etc) that it not possible for me to go into
them
all here Suffice it to say we are talking qualitive differences not
quantitive.

The 'relational' idea of the database is itself in the service of the
overall goal of the whole system. And that is application development.
But a very special method of AD, from procedural to declarative. In other
words, from the traditional procedural method(s) of AD to a methodology
based on 'inference'. It is as if 'performance' as the goal of an sql
optimizer with its emphasis on the physical implementation of sql was
now secondary to the 'logical' model with the emphasis on the compiler
as a logical inference mechanism. In D4 there are no query 'hints' there
are logical 'hints', index hints are replaced with 'key' hints. The user
works with the compiler on a logical level (clarifying which index to
use is replaced with what key(s),reference(s) does a resultant table have).
(As a quick aside, all joins can only be equi-joins. This insures an
unambigious key(s) for the resulting table. Note that the concept
of requiring every result/table (regardless of how it is derived) to
have a key(s) is entirely absent from sql. And yes other predicates can
be used to form tables with other relational operators (see D4 'times'
operator).

The ui in Dataphor is capable of making very detailed windows into
the database exclusively based on inference (views which go way beyond
sql, references and meta-data are key components on which inferences are
based).Of course you can modify the gui to your hearts content I'm
hoping that the integration between the ui and tables in Access
may lead some to explore the sophisticated inference ideas in Dataphor.
I illustrate these ideas with a mini-application that can be downloaded:
http://beyondsql.blogspot.com/2007/0...plication.html

Your points are not about J. C., so even if you want to notify the reader
that you take his objections into consideration, you surely can and have
to mention it, but not as introduction to the point you develop. I refer
to the article where you ... try... to introduce the fact that a table can
be a parameter and you start the discussion by bringing one of the poorest
answer Joe Celko may have ever done in his entire life, of a mathematician
(I say that but take in account that I have a lot of respect for that guy,
for the good stuff he produced).

I respect Joe too. I hope you will forgive me if I take some liberties
Joe implied the logical implausibility of the idea of a 'super function'
in sql. Of course he is correct, in sql. I used that same idea to show
how logically it fits in a relational database. I used his thought
to 'contrast' sql and D4 on the basis of tables as variables. I think/hope
it
worked out As a practical matter it is not easy to communicate
many of these ideas. Joe is a known and respected authority. Perhaps the
reader will stick around and see how things worked out Also bear in mind
these concepts read in a less than compelling way to most. It is hard to
make
them register. That is why I try to show an actual example that derives
from concepts that must be understood for the user to make sense of the
material. I think Joe understands. I have had many exchanges with him
For example see:
(
microsoft.public.sqlserver.programming
Tuesday, August 21, 2007
'Primary key selection'
http://tinyurl.com/39dgcp
(My point here is sql is immature based on its concept of a key. The key
is elevated in D4 to where index is in sql. Note that 'all' types including
tables have a logical 'addressing' mechanism. For tables it is the key(s).
This concept and its usage is completely alien to sql users).
I've also used ideas expressed by Itzik Ben-Gan to contrast sql and D4.
See:
http://beyondsql.blogspot.com/2007/0...entifying.html So I'm at least in fast company, yourself included :-) )I use MS sql server in much the same way. Some concepts make sensein sql (some don't but take on a whole new meaning in D4. Again I usethe contrast to make my point. In this vein I've used dynamic sql and'lists' in sql server to name a few. See:'Sql - History repeats itself simulating lists'http://beyondsql.blogspot.com/2007/07/sql-history-repeats-itself-simulating.htmlIn my opinion, I must say that for optimization of a query plan, I stillfindthat knowing the table, its physical structure, its indexes, its stats,whatis required (what is SELECTed), etc. can make the optimizer find a betterplanthan when having a ... general ... table. Not knowing if you SELECTDISTINCTa primary key or a secondary field, as example, can make some differenceinthe lag the end user is likely to experience, at runtime. Sure, there arecases where the optimized plan will be very fast to obtain (so why notgetting it at runtime), or where it is irrelevant, but I cannot say thathaving a table, as parameter, is on my priority list at all.The general issue of 'performance' will forever rear its ugly headAt this point I have little incentive to get into the details ofoptimizing D4 code regardless if its queries, non-procedural codeor whatever. The basic concepts are hard enough to get across. I fearintroducing details of how certain D4 constructs will gain a performanceadvantage is premature. I would ask that you look at this article forsome perspective on the notion of performance in AD/D4:http://beyondsql.blogspot.com/2007/0...htmlEventually I will address performance head on.Let me introduce some additional info. At this point in its developmentDataphor does not possess its own mature 'native' storage (for developmentyes, for enterprise work no). Dataphor utilitizes a 'device' forstorage. A device can be one of a number of enterprise sql dbs, ie.DB2, Oracle, SAS, Sql Server. I use Sql Server as a device. So the devicecan simply be the data repository. At the most elementary level allDDL commands in the synatax of D4 will throw the data into an sqlserver database. All DML commands in D4 will, when appropriate,access data in sql server going thru a client language interface.The D4 compiler will determine the details of the interaction withthe device. This process is by no means trivial but at the veryleast can be transparent to the user. But channels of communicationare availiable for user intervention. A most common one is whatmost Access users are familiar with, the pass thru query. So theuser can throw any valid t-sql (queries, procedure calls, ddl) tothe server. For t-sql queries and server side procedures that producea result (table) the result will be treated just as if it was derivedvia native D4 syntax. Of course there is nothing preventing a user fromusing dynamic sql. So we come around in a full circle. If one becomes tostressed in the relational world of D4 there is always the option toto go back to the world that time forgot! :-) :-) Your writing style is (still) complex. I know mine is, also, but in thiscontext, my style is not relevant, I think.You have me at a distint disadvantage. But bear in mind sql has beenaround for almost 40 years and talking about it succintly still remainsa burden few can carry. Communicating effectively in the newborn relationalterms, ie types, variables and relvars, is a work in progress. I willhave to take my lumps. But I will try to make effective use of feedbackwhich I wholeheartedly encourage.I haven't see a 'tour guide'. I am not even sure I started at the rightplace! Sure, if the purpose is still to start a discussion, that can beexpected since we don't know where it will go, but there is already a lot ofmaterial (not necessary self contained, I am afraid) and I am still not sureabout 'where' in the process of making an application you want to focus. Youare not spreading your thought about the user interface, aren't you? Ok, itis NOT SQL, it is maybe Access, but WHAT is it? I am a little bit lost, andhave the impression that I could put my hands on great (I hope) pictures ofa movie, but still not sure if the movie is a documentary, or somethingelse.I understand what you are expressing. Start at the beginning, but justwhere is the beginning?To get a jump start, to actually see what D4 scripts are and thesteps that constitute a working example/application see:http://beyondsql.blogspot.com/2007/0...ation.htmlThis is a fully functioning application that includes a ui. But bear inmind one does not need the 'ui' to explore the system. One can learnquite a bit about modelling with sql server without the need for a ui.Creating a single D4 operator/procedure or query will start a user on hisway.Once you start up Dataphor you can tinker with creating tables, queriesor whatever.I would recommend the serious user:Go to www.alphora.com and download Dataphor. Install the beast and startpouring over the documentation to get a feel for this thing (thedocumentationis also availiable online). If you have any version of sql serveryou can quite easily use it as your data store. You can connect toa server database and have access to all tables in the database immediately.For example connect to the Northwind or Pubs database. (If you need a handconnecting contact me via my blog). Start getting familiar with theDataphoria gui. Your going to be doing your development with this ui.It's straightforward just like query analyzer is. You can easily createnew tables in D4 that will reside on sql server. Start browsing therelational operators in help. Try a few queries. Your on your way.My blogAside from the mini-app example, the articles consist of pep talks,explanations and examples (along with their underlying concepts).The examples can all be copied and pasted into Dataphor and run.They work Think of the examples as snapshots. The show differentslices of constructs and concepts (Dataphor comes with many samples too.Be sure to check them when you install Dataphor). Joe Celko has said thatat some point in time when learning sql a light in your head will hopefullyappear. Same thing in D4. At some point it will all come togetherif you bear with it.It seems you mention an interest for the framework (dot.Net) which is ananti-SQL thing (even if they added some element of SQL in version 3.0),imho. Gone the sub-queries, even gone the joins, just a simpleselect-from-where and if you need 'join' or 'subqueries', you use theframework objects that refer to these 'simple' statements, and use C#, orwhatever, not SQL, to carry the 'joins', but without the memory explosionwhat SQL-joins do. On the other hand, from the first impression I got, itseems you add complexity to the SQL language. So, it would be like rootingin the wrong soil, no? Since the framework is about simple, simple SQLstatements, that is (and C# developers are ready to pay the price by writingcomplex C# procedural statements, because they know C#, but not SQL, anddon't want to invest in a more complex SQL like language). I may have thewrong idea of what you saw, though.Dataphor is built with C# a typed language. Conceptually it makes a lot ofsense since D4 is a itself a typed system. The concept of type is one of thefoundations of the 'relational' model. In other words it is logical thatD4, with its reliance on type, be built with a framework that is typed.The fact that D4 is built with a net language in no way implies thatD4 has anything to do with the LINQ/DLINQ project which is what you seem tobe referring to. The idea the MS can 'hide' sql from net developers.What ever games MS is playing with sql from net has nothing to do withD4. But it also means that just like channels of communication from D4 tothe storage(device) ie. sql server, there are channels from D4 to net.So users can write assemblies and interact with the net framework in otherways. And like pass-thru queries, this communication with net does notcome with any hidden price to be paid It can be used to expand thefunctionality of D4, for example user defined types defined with anet language (note that user defined types can be defined quite nicelyfrom within D4). Aside from channels of communication, the net frameworkis 'transparent' to the user. Again MS's communication from net tosql server is totally independent of D4 and its relational language.Some parting thoughts.I have not said anything specific about the relational (query) language.As an expert sql developers you will find it quite different whichis to be expected. You will also find that some query concepts insql will carry over. You will find there are many new constructs,you will find many sql constructs greatly expanded in functionality(constraints, views, procedures to name just a few) and youwill discover new ways of doing things in comparison to sql. Mostof the historical objections to sql (both conceptually and design of thelanguage) are corrected in D4.Mastery of D4 will take an effort, this is not a trivial exercise.But I think you will find it is a great pictureIf you have any questions or just want to chat please feel free tocontact me (thru the blog is fine). People like yourself will onlymake this system better.Lastly, as I state in several articles, D4 does not necessaryeclipse sql. Sql has its place but it is misplaced as a foundationfor application development. For that D4 is best suited.best,steve

Michel,

My reply got garbled. It's on my blog in readable format

http://beyondsql.blogspot.com/2007/0...to-michel.html

best,
steve

I printed it :-)

Thanks,
Vanderghast, Access MVP

"Steve Dassin" wrote in message
...
Michel,

My reply got garbled. It's on my blog in readable format

http://beyondsql.blogspot.com/2007/0...to-michel.html

best,
steve

There is little evidence that the sql community understands the
concept of a table as a variable let alone its significant
implications. Yet there is ample evidence that the sql community
thinks that it is practicing relational principals within an sql
database. This would seem an awkward state of affairs given that
the concept of table types and variables lies at the heart of a
relational database.
Every table created is at inception a table variable. There is
nothing to be done additionally to a table to change it to a
variable. This is a basic concept in a relational database. And
understanding this should lead to the idea that operating on
a table variable is significantly different than operating on
a table that is...well not a variable

I have therefore written a no nonsense and straightforward
article to clearly present the idea of a table as a variable.

http://beyondsql.blogspot.com/2007/0...variables.html

I do hope it helps.

best,
steve