If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#51
|
|||
|
|||
Are there known issues with Vista and Acc2003
On Mar 1, 11:27 pm, "David W. Fenton" wrote: It didn't take a genius to understand that the recommendation by MS to use ADO with Jet data was a mistake. ADO with Jet data may have been a mistake but it happened. Sorry! Wouldn't it be nice if we could rewrite history... In the late 90s MSFT decided on a major revision of (Access2000) including a new version of the engine (Jet 4.0) and had a dilema about whether the native data access technology, DAO, could be enhanced to support the new engine features because it has 'known issues' with its architecture e.g. if you don't explicitly teardown objects *and* in the correct order you will get memory leaks. The SQL Server team, who had rewritten the Jet engine, had a new data access technology (ADO) that was generalized enough to support 95% (or better) of Jet. But MSFT decides to bite the bullet and invest in significantly restructuring of DAO to make it more robust and to have a flatter hierarchy (e.g. stand-alone recordsets), support the new Jet features (e.g. row-level locking) including those not exposed in the Access user interface (e.g. CHECK constraints), introduce some new properties (e.g. paging) and methods (e.g. saving recordsets in XML format), plus introducing events (e.g. asynchronous execution/fetching), including an 'information schema' to be more in line with the SQL-92 standard, plus some 'cool' features which were never going to appeal to the old guard (e.g. hierarchical recordsets). In this version of reality, would these features have enjoyed better take up? Let's say take up was the same and eight years on self-styled experts were still unaware of Jet's CHECK constraints (sorry!). Even then, would the Access community find it acceptable to be expected to rollback to the Access 97 feature set plus just a handful of the new engine's capabilities? I think not and, getting back to reality, that's why I say ADO will remain relevant until DAO functionality has been significantly enhanced (even if they don't ever fix the architecture). Many people tried ADO with Jet and liked it. Sorry! Jamie. -- |
#52
|
|||
|
|||
Are there known issues with Vista and Acc2003
"lyle fairfield" wrote
C'mon Larry. I think you'd be a natural for call-in support. You already speak a dialect that almost no one can understand (Texan), don't you? That's a requirement, I believe. Doan chall drawl, tew? Larry |
#53
|
|||
|
|||
Are there known issues with Vista and Acc2003
"Larry Linson" wrote in
news:AbKFh.6749$tR1.5580@trnddc05: "David W. Fenton" wrote But there was actually a reasonable justification for this: macros can be executed safely (because of the limited set of available commands) and VBA code can't. Help me understand, David, why the VBA code _that is generated by the wizards_ "can't be executed safely". Because there's no way to mark wizard-generated code as a special kind of code that can't have anything dangerous in it. Macros are limited to a finite set of commands. VBA is not. They haven't done away with VBA, they have just done away with the Wizards generating it -- you can create your own event procedures using VBA, but, if you are a developer and going to extend an event procedure, you are going to have to rewrite what they did with the *&$% macros. But is there also not a very easy way to convert the macros to code? I read something about that on one of the Access blogs (probably Clint Covington's). Do I think they have an agenda to eliminate VBA? No, I don't think they do. At least, not until they can replace it with a managed-code solution. Remember, a huge portion of Access itself is written in *Access* and delivered as wizards. If VBA were removed, then those wouldn't work. Yes, indeed I do, unless they have a groundswell of support from _enterprise customers_. VSTO is already there to encourage Word and Excel developers to move to the "wonderful world of DotNet." No amount of bitchin' from "the great Access unwashed" is likely to have any effect. Does VSTO allow you to write managed code for use in Word and Excel? If not, then I don't understand how it's a replacement for VBA in Word and Excel. Frankly, I've been a developer since before Bill Gates was in Junior High School, when he was borrowing time on somebody's minicomputer to learn programming, and much before he founded Microsoft. For me, it's a little late to have an interest in switching to "user software support" -- that's for the interns that the company hires from local colleges to support technical education and scope out promising young new hires. There will always have to be a scripting language in Access. The question is: how full-featured will it be and will it still be able to use API calls. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#54
|
|||
|
|||
Are there known issues with Vista and Acc2003
On Mar 2, 3:31 pm, "David W. Fenton"
wrote: "Larry Linson" wrote innews:AbKFh.6749$tR1.5580@trnddc05: "David W. Fenton" wrote But there was actually a reasonable justification for this: macros can be executed safely (because of the limited set of available commands) and VBA code can't. Help me understand, David, why the VBA code _that is generated by the wizards_ "can't be executed safely". Because there's no way to mark wizard-generated code as a special kind of code that can't have anything dangerous in it. Macros are limited to a finite set of commands. VBA is not. They haven't done away with VBA, they have just done away with the Wizards generating it -- you can create your own event procedures using VBA, but, if you are a developer and going to extend an event procedure, you are going to have to rewrite what they did with the *&$% macros. But is there also not a very easy way to convert the macros to code? I read something about that on one of the Access blogs (probably Clint Covington's). Do I think they have an agenda to eliminate VBA? No, I don't think they do. At least, not until they can replace it with a managed-code solution. Remember, a huge portion of Access itself is written in *Access* and delivered as wizards. If VBA were removed, then those wouldn't work. Yes, indeed I do, unless they have a groundswell of support from _enterprise customers_. VSTO is already there to encourage Word and Excel developers to move to the "wonderful world of DotNet." No amount of bitchin' from "the great Access unwashed" is likely to have any effect. Does VSTO allow you to write managed code for use in Word and Excel? If not, then I don't understand how it's a replacement for VBA in Word and Excel. Frankly, I've been a developer since before Bill Gates was in Junior High School, when he was borrowing time on somebody's minicomputer to learn programming, and much before he founded Microsoft. For me, it's a little late to have an interest in switching to "user software support" -- that's for the interns that the company hires from local colleges to support technical education and scope out promising young new hires. There will always have to be a scripting language in Access. The question is: how full-featured will it be and will it still be able to use API calls. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ I think they do want to eliminate or at least minimize VBA. I also agree with their reasoning. I still hold to many of the predictions I made he http://groups.google.com/group/comp....32d13cf554de71 I said, among other things: My concern is still that MS may be trying to put VBA into legacy mode. If that happens, so that developers are forced into the DotNet world, there will be a tremendous loss of efficiency for developers unless new techniques for customization are developed. I suspect that the new XML tools may be meant to lessen the hit of leaving VBA behind. MS may be ready to put VBA on a pedestal and place a spotlight on it as the development tool of the future. Who knows? I don't see it that way yet. I'm seeing VBA as being a potential sacrifice to DotNet web integration. I am going to take Larry's advice seriously and try to be prepared for any eventuality. Maybe the PDC 05 didn't talk about VBA much because it wasn't in yet. I'm still leaning toward the deliberate de-emphasis theory. Maybe Access will be dumbed down via a VBA lobotomy in the future. It doesn't make sense for MS to push VBA anymore. Besides, some XSLT, C#, and SOAP are good for the soul until we find out how MS really intends to do RAD. Comments from PDC05 on WCF: And we observed that, in most cases, enterprises that are very successful in taking heterogeneous environments and having them work in a cohesive way do messaging. And they do something very important. They do Protocol Integration. That's the way they put things together. They don't stick everything in one system or inside of one database. They just have messages flow between one system to another system. And we committed ourselves at that time, seeing that observation, to doing WCF. And we also committed ourselves at that time to doing full blown interop. That's when we sort of flipped the switch and said, "You know what? We're going to talk to everybody." .... SOAP enables rich extensibility and security. .... Application Protocols: POX [Plain Old XML], RSS, ... Infrastructure Protocols: SOAP, WS-*, ... .... XML is one of our core architectural commitments. .... But the key thing is Protocol Integration, XML and then avail yourself of either Metadata or SOAP as appropriate. But that's where we're betting as a company, on the fact that protocols are important and we've got a lot of investment in WS-* and we're going to continue to do that and we believe that's the center of gravity for us moving forward. .... XML, XML, XML, XML. -- Douglas Purdy, COM 326, PDC05 James A. Fortune |
#55
|
|||
|
|||
Are there known issues with Vista and Acc2003
Hi David
i use SendKeys {f4} to open a dropdown box. What is your solution? "David W. Fenton" wrote: "Di Cook" wrote in : Sendkeys is not supported in Acc2003 programs running under Vista. No serious programmer ever uses SendKeys. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#56
|
|||
|
|||
Are there known issues with Vista and Acc2003
Use the Dropdown method of the combo, e.g.:
Me.[Combo3].Dropdown -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Harald Borchard" Harald wrote in message ... Hi David i use SendKeys {f4} to open a dropdown box. What is your solution? "David W. Fenton" wrote: "Di Cook" wrote in : Sendkeys is not supported in Acc2003 programs running under Vista. No serious programmer ever uses SendKeys. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#57
|
|||
|
|||
Are there known issues with Vista and Acc2003
"Allen Browne" wrote in
: Use the Dropdown method of the combo, e.g.: Me.[Combo3].Dropdown If I'm remembering correctly, the combo box has to have the focus at the time you issue the command (which is not a big deal, as you most likely wouldn't be issuing it anywhere except the OnEnter event). -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#58
|
|||
|
|||
Are there known issues with Vista and Acc2003
yeah I used F4 all the tmie-- even outside of MS Access-- I just wish that
other programs followed this convention Of course, I'd use the .dropdown method over sendkeys.. right? "David W. Fenton" wrote in message . 1... "Allen Browne" wrote in : Use the Dropdown method of the combo, e.g.: Me.[Combo3].Dropdown If I'm remembering correctly, the combo box has to have the focus at the time you issue the command (which is not a big deal, as you most likely wouldn't be issuing it anywhere except the OnEnter event). -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#59
|
|||
|
|||
Are there known issues with Vista and Acc2003
Thank you Allen - that was the exact answer I was hoping for - it made my
week!! "Allen Browne" wrote: Use the Dropdown method of the combo, e.g.: Me.[Combo3].Dropdown -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Harald Borchard" Harald wrote in message ... Hi David i use SendKeys {f4} to open a dropdown box. What is your solution? "David W. Fenton" wrote: "Di Cook" wrote in : Sendkeys is not supported in Acc2003 programs running under Vista. No serious programmer ever uses SendKeys. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
Thread Tools | |
Display Modes | |
|
|