> Also, what isn't supported in the COBOL for .Net. Is inline SQL supported?
> If not, that more of an issue than my problem with the data structures. If
> I can port 90% or more of the code to .Net, is that better or worse than
> COBOL not supporting inline SQL. I'm sure the COBOL solutions has issues
> that it cannot support at well.
May I ask if you've really read a lot of the posts in this thread? If
so, you'd have known why the thing you wanted is silly
in-memory and also why mutating string buffers isn't supported and why that's a
good thing.
Inline SQL is not recommended for maintenance reasons. One should use a
proper module to do the data-access, either through
o/r mapping or through *shiver* stored procs.
> >>Java old, .NET new, looky! we smarter and cheaper - I think these are very
> >>important messages to convey to the client.
>
> Yeah, but you know what they are going to say.... Why can't we handle data
> structures? So in their mind, who's smarter? If COBOL can handle it, why
> not C# and VB? In the end, it's all just MS ilCode.
I give up. :-/
FB
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
