As the author of the message you're replying to didn't specify the backend that he was using for his Access code, I have to assume he was using the Access engine.
Frankly, unless someone is writing transactionally complex code against a serious backend, it's unlikely that they'll realize that the data aware controls that come with Access (& VB) have very limited usefulness.
You're right about ADO recordsets being easy to deal with. In particular I like the simplified syntax that I can use (with late binding) to call stored procedures.
I completely understand the authors painful memories of the MS technology restructuring, though.
Getting back on topic, I agree with others who have noted that the originator of this topic is used to seeing languages through the eyes of the IDE, and that he should first free himself from this view. Secondly, decide whether he is truly looking for a new language or not - as there are many questions he needs to ask himself before he makes a plunge into a new language.
Slashdot Mirror
As the author of the message you're replying to didn't specify the backend that he was using for his Access code, I have to assume he was using the Access engine.
Frankly, unless someone is writing transactionally complex code against a serious backend, it's unlikely that they'll realize that the data aware controls that come with Access (& VB) have very limited usefulness.
You're right about ADO recordsets being easy to deal with. In particular I like the simplified syntax that I can use (with late binding) to call stored procedures.
I completely understand the authors painful memories of the MS technology restructuring, though.
Getting back on topic, I agree with others who have noted that the originator of this topic is used to seeing languages through the eyes of the IDE, and that he should first free himself from this view. Secondly, decide whether he is truly looking for a new language or not - as there are many questions he needs to ask himself before he makes a plunge into a new language.