 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / General 1 / March 2006Is ADO dead?
MSDN Home > MSDN Library > Win32 and COM Development Data Access Microsoft offers many data access technologies to suit various development needs. This section of the MSDN Library contains technical information about current data access technologies, focusing on the Microsoft Data Access Components (MDAC): ADO, OLE DB and OLE DB Providers, and ODBC. Articles on ADO.NET, Microsoft Data Engine (MSDE), and some XML for Analysis (XMLA) material are available here as well. You'll also find information about legacy technologies such as DAO and OLAP Services. Check out the Data Access and Storage Developer Center Look here for orientation, guidance, new information, downloads and code samples on the latest in data access and storage technologies, including ADO.NET, SQL Server, MDAC, and WinFS. In This Library Section Essentials * MDAC Documentation * ADO Documentation * ODBC Documentation * OLE DB Documentation * OLE DB Provider for Internet Publishing * Diving Into Data Access * MSDE Technical Articles * Data Access Downloads * ADO.NET Documentation * ADO Code Samples * XML for Analysis Specification * MSDE Product Information * Data Technologies Support Center * Newsgroups > * MSDE Technical Articles > > * MSDE Product Information Well, we know that MSDE is dead.  SignatureDarryl Kerkeslager >> * MSDE Technical Articles >> >> * MSDE Product Information > > Well, we know that MSDE is dead. Well, not dead, but renamed, which suggests that any documentation using the term "MSDE" is out of date, and, perhaps obsolete. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > Well, not dead, but renamed, which suggests that any documentation > using the term "MSDE" is out of date, and, perhaps obsolete. No - it is dead - in the same sense that people have referred to ADO and DAO as dead - it is no longer being developed. In fact, MSDE is more dead than DAO, in that there is no longer any logical reason to use it, as SQL Server Express more than takes the place of it. SQL Server Express is not MSDE, any more than ADO.Net is ADO, or MSDE is SQL Server. SignatureDarryl Kerkeslager > > Well, not dead, but renamed, which suggests that any documentation > > using the term "MSDE" is out of date, and, perhaps obsolete. [quoted text clipped - 9 lines] > -- > Darryl Kerkeslager This is interesting. In spite of it being called Access 12, Microsoft is really eliminating Access and VBA. SQL Server Express for the data and .NET for the interface with definitions and reporting in XML. [cliche alert] It's starting to look like they dumped the RAD baby out with the bathwater. That is, unless you falsely imagine that the extra flexibility MS designed into Access 12 reporting will be able to handle every situation. MS had good reasons for going in these directions so I'll try not to mourn the death of Access too long. I'll do the best I can to create a RAD environment without what we once understood Access to be. [cliche alert] Putting Access' clothes on .NET reminds me of a certain silk pigskin wallet. [cliche alert] It seems that the reports of Access' demise were not premature. James A. Fortune CDMAPoster@FortuneJames.com >> > Well, not dead, but renamed, which suggests that any >> > documentation using the term "MSDE" is out of date, and, [quoted text clipped - 16 lines] > Express for the data and .NET for the interface with definitions > and reporting in XML. Huh? Where in the world are you getting this information? Surely not from the Access 12 blog on MSDN, which has said nothing of the sort. > [cliche alert] It's starting to look like they dumped the RAD baby > out with the bathwater. . . . If your major premise is wrong, your minor premise cannot be proven. > . . . That is, unless you falsely imagine that the extra > flexibility MS designed into Access 12 reporting will be able to > handle every situation. . .. They are keeping the same report designer UI and adding a new Layout view, which is like an editable print preview. Sounds like a good thing to me -- use the old methods where they work best, and the new ones where those are better. How the report definition is actually stored is really completely irrelevant to me, as I don't have access to that, in any case, unless I want to do a SaveAsText (which I never do, unless I'm trying to recover a corrupted report). > . . . MS had good reasons for going in these directions so > I'll try not to mourn the death of Access too long. . . . What in the world are you talking about? > . . . I'll do the best I > can to create a RAD environment without what we once understood > Access to be. [cliche alert] Putting Access' clothes on .NET > reminds me of a certain silk pigskin wallet. [cliche alert] It > seems that the reports of Access' demise were not premature. Are you completely insane? None of the things you are talking about are going to happen according to the official Access blog on MSDN. None. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > >> > Well, not dead, but renamed, which suggests that any > >> > documentation using the term "MSDE" is out of date, and, [quoted text clipped - 19 lines] > Huh? Where in the world are you getting this information? Surely not > from the Access 12 blog on MSDN, which has said nothing of the sort. It's possible that ADO and DAO will be available in Access 12 but SQL Server Express without VBA definitely seems to be where MS is heading. I have not seen any indication anywhere that VBA will be able to be used in Access 12 at all. I may be wrong. If you need to customize the output before or after it's created you need something like Visual Studio or FrontPage or something else. XML is not just used as a storage mechanism. If Access 12 can't create the XML you need, then VBA is not an option. > > [cliche alert] It's starting to look like they dumped the RAD baby > > out with the bathwater. . . . > > If your major premise is wrong, your minor premise cannot be proven. That may be so, but VB.NET or C# is quite a bit slower to develop in than VBA. > > . . . That is, unless you falsely imagine that the extra > > flexibility MS designed into Access 12 reporting will be able to [quoted text clipped - 4 lines] > thing to me -- use the old methods where they work best, and the new > ones where those are better. No VBA behind a report. So much for the old methods. If you're happy with what Access 12 can do natively then things are better with the new design. > How the report definition is actually stored is really completely > irrelevant to me, as I don't have access to that, in any case, > unless I want to do a SaveAsText (which I never do, unless I'm > trying to recover a corrupted report). The XML for the report is already in plain text. SaveAsText won't help corrupted reports. You'll need to start indenting the XML source for that :-). > > . . . MS had good reasons for going in these directions so > > I'll try not to mourn the death of Access too long. . . . > > What in the world are you talking about? Everything needed to move toward something that would work for the internet/intranet world. I was talking about eliminating VBA and the way mdb files are stored. Those are good things in the long run. I just need to find something that makes up for the loss of VBA. > > . . . I'll do the best I > > can to create a RAD environment without what we once understood [quoted text clipped - 6 lines] > > None. I don't think it's going to be Access anymore. I think it's going to be SQL Server and .NET with some flexible XML writing thrown in. I think it's going to be more powerful than before. I think the development process will be slower. Visual C++ is extremely powerful but I don't design databases with it. I hope you're correct about being able to use ADO or DAO like before without resorting to .NET coding. I don't think that the new flexibility that reports are going to have is enough to justify calling the new .NET thing Access. Even custom SQL will have to be part of the .NET code. [mangled cliche alert] If it looks, sounds and acts like .NET then it is a dog :-). James A. Fortune CDMAPoster@FortuneJames.com James where in the world did you read that VBA is no longer available with Access 12? Do you know how ludicrous your statement is? SignatureHTH Stephen Lebans http://www.lebans.com Access Code, Tips and Tricks Please respond only to the newsgroups so everyone can benefit. >> >> > Well, not dead, but renamed, which suggests that any >> >> > documentation using the term "MSDE" is out of date, and, [quoted text clipped - 93 lines] > James A. Fortune > CDMAPoster@FortuneJames.com > James where in the world did you read that VBA is no longer available with > Access 12? Do you know how ludicrous your statement is? Whew. I'm glad it was ludicrous. I thought VBA was history. Lyle Fairfield wrote: :Yes you may. Whew. I'm glad I'm allowed to be wrong every now and then :-). James A. Fortune >> James where in the world did you read that VBA is no longer >> available with Access 12? Do you know how ludicrous your >> statement is? > > Whew. I'm glad it was ludicrous. I thought VBA was history. Do you realize what a dis-service you've done to this newsgroup by posting the things you've posted here? You've created a set of rumors that someone searching Google Groups may encounter, which may end up as misinformation that propagates far beyond this particular thread. If you didn't have any actual proof for any of your assertions, then you shouldn't have made such ridiculous statements. I'm beginning to recall now why I had killfiled your previous email address. I haven't yet decided if I'll be plonking this one, too. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > I'm beginning to recall now why I had killfiled your previous email > address. I haven't yet decided if I'll be plonking this one, too. Please do. You're too uptight and I don't want to stress you out. James A. Fortune CDMAPoster@FortuneJames.com Hi I have a question about how to create an index using code in MS Access 2003 after the code has run a make table query in the same database. I would Also like to adapt it so that a table I created in another database using a Make table query has an index created next time I open the other database. I think I would use the ADO append methode with the index collection but not clear on how to do the code. I assume you would identify the table collection and specific table to work on then append the index but can not find any examples. Any assistance would be appreciated. Greg Easiest way is to use a DDL command. CREATE [UNIQUE] INDEX <index name> ON <table name> (<column list>) E.g.: CREATE INDEX idx_SalesDate ON Orders (sales_date) Use an ADO connection's Execute method to run the command. See the Access Help articles under "SQL Reference." SignatureMGFoster:::mgf00 <at> earthlink <decimal-point> net Oakland, CA (USA) > Hi > [quoted text clipped - 9 lines] > I assume you would identify the table collection and specific table to > work on then append the index but can not find any examples. MGFoster Thanks for the quick response I will try it out and see how I go Regards Greg > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 [quoted text clipped - 10 lines] > > See the Access Help articles under "SQL Reference." > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Easiest way is to use a DDL command. > > CREATE [UNIQUE] INDEX <index name> ON <table name> (<column list>) I agree, but I also want to point out that DAO tabledefs have a CreateIndex method and that there is a Collection of Index objects. James A. Fortune CDMAPoster@FortuneJames.com Our business is to establish peace and order on a satisfactory basis, start the new government, and then leave the Island; the Cuban Government taking the reins into its own hands; tho of course it might be advisable for some little time that some of our troops should stay in the Islands to steady things. --- Theodore Roosevelt 1907 > It's possible that ADO and DAO will be available in Access 12 but SQL > Server Express without VBA definitely seems to be where MS is heading. > I have not seen any indication anywhere that VBA will be able to be > used in Access 12 at all. I may be wrong. Yes, you may. >> > This is interesting. In spite of it being called Access 12, >> > Microsoft is really eliminating Access and VBA. SQL Server [quoted text clipped - 6 lines] > > It's possible that ADO and DAO will be available in Access 12. . . It's not only "possible" but it's what MS is promising. Access 12 is going to be backwardly compatible. And I can't recall any statements that it's going to introduce any form of .NET into Access. > . . . but SQL > Server Express without VBA definitely seems to be where MS is > heading. . . Not for Access. I believe that you are completely misinformed. What Access 12 is actually going to offer is a new default db engine that is derived from (and backwardly compatible with) Jet. See: http://blogs.msdn.com/access/archive/2005/10/13/480870.aspx > I have not seen any indication anywhere that VBA will be able to > be used in Access 12 at all. . . . I think you've got it entirely upside-down. I have seen absolutely no indication anywhere in the voluminous writings from Microsoft employees about the new Access 12 that indicate an abandonment of VBA and any significant move to .NET (except for add-ons, i.e., code that is external to Access). But, please, show me where on the Access blog that it says VBA is out and .NET will replace it: http://blogs.msdn.com/access/ > . . . I may be wrong. . . . I think you are completely mistaken. There are a lot of new features described in this "what's new" article: http://blogs.msdn.com/access/archive/2005/11/07/490113.aspx But not once is any change to VBA or incorporation of .NET mentioned. I'd think that would be a major issue if it were happen, and not something that MS would be completely silent about. But if you have a link where an authoritative source from MS has said that VBA is being abandoned in Access in favor of .NET, then, please, provide the documentaiton for it. > . . . If you need to customize > the output before or after it's created you need something like > Visual Studio or FrontPage or something else. XML is not just > used as a storage mechanism. If Access 12 can't create the XML > you need, then VBA is not an option. This is all so much fantasy. It has no basis in any reality that Microsoft has described for Access 12. >> > [cliche alert] It's starting to look like they dumped the RAD >> > baby out with the bathwater. . . . [quoted text clipped - 4 lines] > That may be so, but VB.NET or C# is quite a bit slower to develop > in than VBA. Those are irrelevant, as THEY AREN'T GOING TO BE INCORPORATED INTO ACCESS 12. That's what I meant by "major premise" -- the assertion about VBA being dropped is simply WRONG, thus any comments about relative RAD capabilities and speed are just nonsensical. >> > . . . That is, unless you falsely imagine that the extra >> > flexibility MS designed into Access 12 reporting will be able [quoted text clipped - 6 lines] > > No VBA behind a report. . . . Where is this stated? Nowhere, so far as I can see. The Access 12 blog recently had a post with extensive discussion of the new report designer: http://blogs.msdn.com/access/archive/2006/02/13/531116.aspx Nowhere in there does it say anything about there being no VBA code behind the report. Of course, it doesn't relaly discuss coding, because the focus of the post is on the end-user aspects of Access, rather than the developer aspects. Indeed, statements like this: Easier to extend Access apps with Visual Studio despite our best efforts, Access will not offer all the power of Visual Studio, and for some tasks developers will want to use VS. We believe a key part of the strategy needs to be to make it easy for VS developers to extend Access apps without having to re-write them. Office 12 does this to some extent (e.g. workflows written in the SharePoint Designer can be easily edited in VS), but there is clearly more to do here. from this post on "Access's Commitment to Developers": http://blogs.msdn.com/access/archive/2005/11/30/498466.aspx You'd think that if what you say is true, this quotation that shows substantial distancing between Access and VS would simply make no sense. > . . . So much for the old methods. If you're happy > with what Access 12 can do natively then things are better with > the new design. There is no evidence anywhere that Access 12 is going to remove the old ways of doing things. Indeed, in the discussion of the new layout view in the report designer, the point is made quite clearly that the old design view is still going to be available because a lot of tasks remain that will be better accomplished in that view than in layout view. The completely absence of any mention of the elimination of VBA suggests to me that it's going to be there. And the repeated insistence on backward compatibility suggests to me that you are wholly mistaken in your assertions about about VBA and .NET in Access 12. >> How the report definition is actually stored is really completely >> irrelevant to me, as I don't have access to that, in any case, [quoted text clipped - 4 lines] > help corrupted reports. You'll need to start indenting the XML > source for that :-). Non sequitur. The point is that if the UI for designing and using the report, and the coding environment remain the same, a change in the storage format is completely irrelevant for 99.99% of Access programmers and end users. It's only the small number of cases where you've built something that depends on the undocumented SaveAsText that you'd run into a problem if the storage format has changed. I have seen nothing in the information distributed about Access 12 that says you'll be designing your reports by manipulating XML directly. If you have information from MS that says this is so, then, please, provide a citation of it. >> > . . . MS had good reasons for going in these directions so >> > I'll try not to mourn the death of Access too long. . . . [quoted text clipped - 6 lines] > run. I just need to find something that makes up for the loss of > VBA. THERE IS NO LOSS OF VBA. THERE IS NO LOSS OF THE MDB FILE FORMAT. THERE IS NO MOVE TOWARDS DIRECTLY MANIPULATING XML FOR REPORT DESIGN. You are simply wrong on all counts about what is happening with the design of Access 12. I've seen for years many people speculating that what you describe would happen with the post-2003 version of Access, but it isn't happening after all. Your assertions seem to me to be derived from all the baseless speculation from people outside Microsoft and outside the Access development team. My information is based on information direct from one of the leads of the Access development team. >> > . . . I'll do the best I >> > can to create a RAD environment without what we once understood [quoted text clipped - 9 lines] > > I don't think it's going to be Access anymore. . . . THe key words there appear to me to be "I think." But you have absolutely no factual basis for making these claims. > . . . I think it's going > to be SQL Server and .NET with some flexible XML writing thrown > in. . . . Well, then you're just WRONG. It's going to be the new Access db engine (which is derived from Jet and backwardly compatible with Jet) with VBA and no required XML manipulation. > . . . I think it's going to be more powerful than before. I think > the development process will be slower. . . . So far as I can see, we already have what you're describing by simply using the existing .NET development tools. There would be no utility whatsoever in making Access like those tools, because Microsoft would then have two products that are nearly identical in functionality. Secondly, such a set of tools would not serve the end-user market at all. It's quite clear from the posts on the Access blog that the Access team is putting a huge amount of effort into enhancing Access's user-friendliness for non-programmers. That move is in direct contradition of all your assertions about the loss of RAD, since the RAD features in Access come directly out of the end-user ease-of-use features. > . . . Visual C++ is extremely > powerful but I don't design databases with it. I hope you're > correct about being able to use ADO or DAO like before without > resorting to .NET coding. . . . I don't know (or care) about ADO, but Jet is not going away. It is, in fact, getting a new lease on life, with significant new development resources going into it. Yes, it will be a different version of Jet with different capabilities, but that's a *good* thing, in my opinion. Now, I'm not wholly pleased with all aspects of the direction of Access 12. For instance, it's quite clear that Jet replication is going to be deprecated in favor of SharePoint services. What that means is that those who want data shared at multiple sites are going to have to add a server to the mix, and spend extra money for server software and infrastructure in addition to the development costs involved, whereas with Jet replication, there was no need for additional servers or software (though development costs are significant). I'm not thrilled with the SharePoint integration in general (not just with regard to replication), since I just don't see the value. I don't understand the concepts behind it (which the Access 12 blog seems to me to treat as something everybody should already know about) and I don't see any value in it for my clients. It looks like another example of enterprise-friendly design being stovepiped onto the small business user. Microsoft Outlook's connection to Exchange Server is a past example of this, where the software product was basically pretty much useless without the back end server in place -- it promised things it couldn't deliver without introducing a very difficult to maintain server into your network (Exchange 2003 is much easier to administer than previous versions, but it's still a bitch compared to not having to maintain a separate server). Perhaps I'm wrong about this. Perhaps SharePoint services can be run on a workstation, peer-to-peer, and perhaps they are easy to administer. I don't know. But I still don't understand what needs they satisfy -- I have no clients who are crying out for collaborative document sharing. None. So, I don't see that the effort going into making Access SharePoint-friendly is going to help any of my clients at all. My best hope is that it won't promise things (like shared calendars in Outlook) that can't be delivered without the server, and that the features necessary to support it won't make the product without it more difficult or more confusing to use. > . . . I don't think that the new flexibility > that reports are going to have. . . You mean "layout view" or are you talking about your imaginary XML editing of reports? > . . . is enough to justify calling the > new .NET thing Access. . . . There is no such thing as a product called "Access" with .NET incorporated into it. > . . . Even custom SQL will have to be part of > the .NET code. [mangled cliche alert] If it looks, sounds and > acts like .NET then it is a dog :-). You are completely in fantasy land. There is no support anywhere in the materials describing Access 12 that supports any of your assertions about what Access 12 is going to be. None. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ >> Well, not dead, but renamed, which suggests that any >> documentation using the term "MSDE" is out of date, and, perhaps [quoted text clipped - 8 lines] > SQL Server Express is not MSDE, any more than ADO.Net is ADO, or > MSDE is SQL Server. Exactly how is SQL Server Express not MSDE renamed? Isn't it just a throttled version of SQL Server, just like MSDE? SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > Exactly how is SQL Server Express not MSDE renamed? Isn't it just a > throttled version of SQL Server, just like MSDE? Scaled down, but not really "throttled" like MSDE was. MSDE had this "feature" (MSDN): In summary, the workload governor in the database engine for SQL Server 2000 Desktop Engine (MSDE 2000) and SQL Server 2000 Personal Edition works by counting active operations. When there are more than eight active operations at the same time in the same instance of the database engine, the governor implements a slight wait before each logical read or write to a data file. For the amount of work typical in databases used by single users or small workgroups, the cumulative effect of the waits is not noticeable. In systems that are reading and writing large amounts of data, the cumulative affect of all the waits slows the performance of the database engine. Below is the comparison between 2005 SQL Server editions. http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx From http://www.databasejournal.com/features/mssql/article.php/3492296: Microsoft repeatedly uses the phrases "simple applications", "lightweight," and "mobile or web applications" when describing the target uses for SQL Server Express 2005. However, the generous restrictions of Express make it an ideal database for many applications. Express is limited to 1 CPU, 1 GB RAM, and 4 GB Max database size. There is NO workload governor (See July article SQL Sever 2000 MDSE for a complete description of the workload governor). Meaning SQL will not slow, or restrict its response times due to licensing constraints. SQL Server Express can be installed on a machine with multiple CPUs and RAM in excess of 1 GB, but the database engine will limit scheduler threads to one, meaning only one CPU will be used. Similarly, the buffer pool, where data pages are stored, will only use 1 GB of RAM, regardless of any additional memory available. Enterprise features are not supported on SQL Express. Missing are Analysis Services, Reporting Services, DTS, and Notification Services. Aside from these restrictions, the SQL Server Express database engine is the same one found in the other SQL products. Triggers, cursors, views, stored procedures, CLR, XML, and TSQL are all supported the same way they are in any other version of SQL Server. Note that the 4 GB Max database size does not prevent you from working around this by using more than one database. Also *not* mentioned, but pretty important, is that you can *easily* detach and copy mdf files from one PC to another - someting I guess you can't do so easily with other SQL Server editions. -------------------------------- While the differences are not huge between the engines, what is *completely* different is that SQL Server Express has a GUI in the free Visual Web Developer Express 2005 and also in the free versions of VB Express 2005, C# Express 2005, etc. SignatureDarryl Kerkeslager >> Exactly how is SQL Server Express not MSDE renamed? Isn't it just >> a throttled version of SQL Server, just like MSDE? > > Scaled down, but not really "throttled" like MSDE was. Well, the differences are interesting, but the assertion that the differences between MSDE and SQL Server Express are like the differences between ADO and ADO.NET is completely wrong, don't you think? SQL Server Express is still SQL Server. It responds to the same commands and serves the same data, it just has slightly different limitations. The fact that there is now a separate piece of software that provides a free GUI is really pretty much irrelevant to a comparison of MSDE and SQL Server Express, since by acquiring other software you could have a GUI for administering MSDE, too (though perhaps you'd have to buy something to get it). In the end, though, all of this does show that documentation that refers to MSDE is out of date, and, thus, using that MSDE documentation to show that ADO is still recommended for current MS products basically goes out the window. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.