Re: The Lambda lambada...Why embedded SQL is becoming irrelevant

Top post:
Remembering, of course, that C# is Microsoft's attempt to
counter Java ..... some hope they've got!

I started playing this link, but at 29 minutes length & screwed
up color, gave up.

Does it have anything to say about Access & the
relational-paradigm busting new data-type Microsoft have come
up with (i.e multi-valued 'fields'?)

Regards

Michael

Pete Dashwood wrote:
> Many people working in COBOL on both mainframe and Client/Server systems
> deal with queries against relational data every day.
>
> Over the years we have become adept with it and can usually get it to do
> whatever we want. Most of us are satisfied we have this particular base
> covered.
>
> But, there are severe limitations in the "imperative programming" approach
> as implemented by COBOL and other languages where we embed SQL.
>
> If you are interested in where SQL is going, WHY the current approaches wi
ll
> not be suitable for emerging architecture, and getting some straightforwar
d
> conceptual information from the horse's mouth, you may find this video
> interview of interest..
>
> [url]http://wm.microsoft.com/ms/msdn/visualcsharp/anders_2007_01/Anders_0001.wmv[/url
]
>
>
> Functional programming represents the extension of the OO paradigm into th
e
> next dimension. The interview with Anders Hejlstrom (who invented C#, amon
g
> other impressive credentials) is in plain English, and most programmers fr
om
> any background will be able to follow it.
>
> (If you at least understand OO terminology it is helpful, but not essentia
l.
> There are a number of references to "IL"; this is "Intermediate Language"
> and, for the purposes of this discussion, can be considered as you would
> "machine code")
>
> I have stopped using the "embedded SQL" approach with cursors and seqentia
l
> processing for some months now (mainly since I moved to C#, where the
> alternatives are preferred and actually easier to implement...) and operat
e
> instead on datasets, result sets, data and table adapters. I did this
> originally because it meant less connect time and allowed connections to
> databases to be shared and pooled in a much better way. (Also, queries
> operate much better when they are directed at in-memory objects than when
> they are directed at external disk files). After viewing the above intervi
ew
> a couple of times I am now understanding why it is important to break away
> from embedded SQL.
>
> This is NOT the end of SQL!! (If you haven't already, start learning it...
> :-)) It is the end of "embedded SQL" as we currently understand it...
>
> Data that can be in any format, from any source, is what the future "SQL"
> must deal with, and it must be capable of dealing with it concurrently
> across multiple cores.
>
> Can it be done?  Hejlstrom thinks it can.
>
> I'd be interested to hear what people here think.
>
> Pete.
>
>
>