I'm all ears, Doug. Have you an example of how to do as you propose,
or a reference/link on the net?

I think what's anemic is my understanding of ASP.NET and web
programming. With Client/Server applications I can well see the value
of the extra layer. But with the web, I don't know how I'd get one
ASP.NET app to serve data to another. I'm barely able to get one web
application working at all using Visual Studio 2003 C# and Firebird.
And, anyway, I thought that was the point of the 'code behind' stuff -
to separate the server code from the client page (application?). The
sea of documentation on these topics doesn't help much because I don't
know what it is that I don't know. Maybe next year I'll have it
figured out.

Pete

>
> Except that you are subject to the DB server's anaemic stored procedure
> language and the fact that it is proprietary to each RDBMS!
>
> Actually, I think the preferred solution is to create an application

server

> between the app and the DB. Have this app server talk objects to the

app

> and SQL to the data store. The extra layer always seems to add

complexity

> but the simplified interfaces and increased modularity win out in

the end!