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 |
#11
|
|||
|
|||
Are there known issues with Vista and Acc2003
On Feb 27, 11:20 pm, "David W. Fenton"
wrote: you took the "no longer recommended" path and stuck with DAO, even for new projects. Isn't it reasonable for someone to take the same approach now with ADP, ADO, etc? No, it is not. think about the difference between a native technology and a translation layer Oops, missed this earlier! That's a valid point against ADO if you are only interested in performance. Now think about data integrity: some database constraints (including primary keys) cannot be implemented with indexes and Validation Rules alone (big hint: table-level CHECK constraints). But that that's just two issues out of many so let's not do the ADO vs DAO thing again here and instead focus on the question in hand i.e. should one avoid a feature (ADP) merely because 'Micosoft support' no longer recommends it? Jamie. -- |
#12
|
|||
|
|||
Are there known issues with Vista and Acc2003
On Feb 27, 11:20 pm, "David W. Fenton"
wrote: you took the "no longer recommended" path and stuck with DAO, even for new projects. Isn't it reasonable for someone to take the same approach now with ADP, ADO, etc? No, it is not. think about the difference between a native technology and a translation layer Oops, missed this earlier! That's a valid point against ADO if you are only interested in performance. Now think about data integrity: some database constraints (including primary keys) cannot be implemented with indexes and Validation Rules alone (big hint: table-level CHECK constraints). But that that's just two issues out of many so let's not do the ADO vs DAO thing again here and instead focus on the question in hand i.e. should one avoid a feature (ADP) merely because 'Micosoft support' no longer recommends it? Jamie. -- |
#13
|
|||
|
|||
Are there known issues with Vista and Acc2003
On Feb 28, 2:03 am, "Baz" wrote:
When will you get it? ADO is dead. D-E-A-D DEAD. If DAO has problems in Vista and/or Acc 2007, it is once again a supported MS product so there is at least a chance that the problems will get fixed. What will happen if ADO has problems under Vista? Nothing, absolutely nothing, not now, not ever. Why? Because it's DEAD. This is completely untrue. |
#14
|
|||
|
|||
Are there known issues with Vista and Acc2003
On Feb 28, 4:01 am, "onedaywhen" wrote:
On Feb 27, 11:20 pm, "David W. Fenton" wrote: you took the "no longer recommended" path and stuck with DAO, even for new projects. Isn't it reasonable for someone to take the same approach now with ADP, ADO, etc? No, it is not. think about the difference between a native technology and a translation layer Oops, missed this earlier! That's a valid point against ADO if you are only interested in performance. Now think about data integrity: some database constraints (including primary keys) cannot be implemented with indexes and Validation Rules alone (big hint: table-level CHECK constraints). But that that's just two issues out of many so let's not do the ADO vs DAO thing again here and instead focus on the question in hand i.e. should one avoid a feature (ADP) merely because 'Micosoft support' no longer recommends it? Jamie. -- ROFL! |
#15
|
|||
|
|||
Are there known issues with Vista and Acc2003
On Feb 28, 7:03 am, "Baz" wrote:
When will you get it? ADO is dead. D-E-A-D DEAD. If DAO has problems in Vista and/or Acc 2007, it is once again a supported MS product so there is at least a chance that the problems will get fixed. Well, another point in the somewhat tiresome 'ADO vs DAO' debate is there remain ADO functionality (e.g. fetching records asynchronously) absent from DAO and there remain areas of Jet functionality inaccessible with DAO (see http://msdn2.microsoft.com/en-us/lib...fice.10).aspx). It seems reasonable to me to continue to use ADO for such things until DAO has caught up with ADO. What will happen if ADO has problems under Vista? Nothing, absolutely nothing, not now, not ever. Why? Because it's DEAD. You're sure about that, are you? See: ADO History http://msdn2.microsoft.com/en-us/library/ms676506.aspx "ADO 6.0 is included in Windows Vista, as a part of the Windows Data Access Components (Windows DAC) 6.0. ADO 6.0 is functionally equivalent to ADO 2.8." Jamie. -- |
#16
|
|||
|
|||
Are there known issues with Vista and Acc2003
On Feb 27, 6:20 pm, "David W. Fenton"
wrote: "onedaywhen" wrote roups.com: What about, for example, back in 2000 when the "Access development and support team at Microsoft" were saying things such as, "In previous versions of Access, Data Access Objects (DAO) was the primary data access method. That has now changed. Although DAO is still supported, the new way to access data is with ADO." (http://msdn2.microsoft.com/ en-us/library/aa140015(office.10).aspx)? My impression is that you took the "no longer recommended" path and stuck with DAO, even for new projects. Isn't it reasonable for someone to take the same approach now with ADP, ADO, etc? No, it is not. HTH. (think about the difference between a native technology and a translation layer) -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ David has used ADO not at all, or very little. He has not studied it. He has neither the skills nor the experience to implement it, yet he constantly denigrates it and expresses absolute opinions about it. David is not alone. He is joined by MVPs and other experienced Access developers. I often wonder why. Is it because they are inherently conservative and do not trust this new (what 1998?) technology? Is it because they have a cozy business based upon Access and DAO? Is it because they do not have the intellectual capacity to keep several technologies active in their brains at the same time? I don't know. I don't care. I can and have used DAO and ADO extensively. I have forgotten more about DAO than many of its champions know; I have used ADO more extensively than most. Each is a fine technology. I like ADO; it has a broad list of capabilities and it has a broad list of situations in which it can be used. The notion that it is dead is absurd. But when it's advantageous to use DAO, I use DAO. What I do care about and think that this newsgroup avoids is not the future of ADO, nor of DAO. It is the future of Microsoft. Ten years ago Microsoft did everything better; it was vibrant and it was developing technologies which were needed and wanted. Today it is developing redundant technologies to hawk. I have learned all about .Net except for one tiny thing: where I would want to use it. Oh I know, it's Superior! And it may be for some. But I have not found that it is superior for an experienced programmer/developer. And no, I don't like apps which can do in ten thousand lines what I used to do in eight (no, not eight thousand lines, eight lines). The computer on which I am writing has Windows and its associated technologies such as Internet Explorer installed. But it is fully provisioned with other [FREE] software that is not Microsoft. How much am I missing Microsoft? Not at all? What have I been unable to do that I could do with Microsoft ? Not a thing. How many crashes/ failures have I had with this new software during February? None. How often and big are the updates? I don't know because invariably the updates are so simple and swift that I forget that they happened. I re-installed Windows XP from the original OEM cds last week and was hit by a total of 113 updates. One hundred and thirteen! Next I turned on a new Vista computer. Ah, I thought, they'll be sure to have this very annoying updating cured. WRONG! Seven updates were required. After three weeks there were SEVEN F___KING updates required. SEVEN F___KING updates required after three weeks of availability. (Sorry, it seems I have repeated myself) Is this Microsoft company a JOKE or what? It's not DAO or ADO that is deficient or dying. They're both great in Microsoft land. But the rain isn't falling on Microsoft land much any more. And the soil is drying up. And there are skeletons on the plains. No one is noticing. But someday soon we will look at the old vista we remember, and it won't be the same. Now I'm cutting this and pasting it into Word or SWrite (Open Office) to check spelling and grammar. Can you tell which I used? |
#17
|
|||
|
|||
Are there known issues with Vista and Acc2003
On Feb 28, 10:59 am, "Lyle Fairfield" wrote:
David [W. Fenton] has used ADO not at all, or very little. He has not studied it. He has neither the skills nor the experience to implement it, yet he constantly denigrates it and expresses absolute opinions about it. David is not alone. He is joined by MVPs and other experienced Access developers. I often wonder why. Is it because they are inherently conservative and do not trust this new (what 1998?) technology? Is it because they have a cozy business based upon Access and DAO? I don't think that's correct. JRO is an ADO component (see http://msdn2.microsoft.com/en-us/library/aa189021.aspx) and David knows more about JRO than most, including me and I'm an ADO advocate. ADO isn't so different from DAO and undoubtedly David processes the required skills, so it's not that either. Rather, I think David just hasn't *really* tried ADODB and he does not possess the normal 'don't knock it until you've tried it' mentality (for better or worse). Generally speaking, I think Access MVPs and other Access 'power users' have really tried it and most do use it when appropriate, or at least are prepared to post it in these groups. However, for the vast majority of functionality it makes little difference whether you use DAO and ADO. I like to say it's a 'lifestyle' choice and I think you shouldn't go around trying to make people feel bad about 'lifestyle' choices they've made; again, most MVPs seem to align with this (David may not). Then again, I don't think anyone should be calling people "idiot" (personal abuse being against the rules of these groups) but wouldn't it be a dull place if everyone though and spoke like me g? One of the most convincing arguments in favour of DAO is there are more DAO code samples available than ADO, because it has been around longer (is it *ever* justified to convert existing DAO code to functionally-equivalent ADO or vice versa?) I get the feeling Access MVPs generally prefer DAO because they have generally been around longer. And it's self-perpetuating e.g. want to be an MVP (or seeking re-election)? then act like an MVP and use DAO. Anyone remember VHS vs Betamax? Technical superiority Best does not always secure the popular vote. Jamie. -- |
#18
|
|||
|
|||
Are there known issues with Vista and Acc2003
On Feb 27, 9:53 pm, Tim Marshall
wrote: What about, for example, back in 2000 when the "Access development and support team at Microsoft" were saying things such as, "In previous versions of Access, Data Access Objects (DAO) was the primary data access method. That has now changed. Although DAO is still supported, the new way to access data is with ADO." (http://msdn2.microsoft.com/ en-us/library/aa140015(office.10).aspx) Try calling MS support now. They recommend DAO with jet. My point! 50K lines of code is easy to come up with. Do you know what a computerized maintenance mangement system is that controls work assignment, inventory, purchasing, maintenance and PM schedules, workers' hours, contractors, equipment, asset, building, room, vehicle and hundreds of other lists of things facilities managers look after? 50K is nothing. Some of us write and maintain very large applications. Boasting aside, what does line count tell us? I could take 10K lines of dense 'Sub Main' style VBA code and make it OOP (build an object model using a parent class plus child classes including collections classes), add code comments and white space, make long lines of code into several smaller ones (e.g. using continuation lines), etc and end up with a line count of 50K that are functionally equivalent and easier to read and maintain. I could take 50K lines of 'dynamic SQL' style VBA code and create views and procs in the database and use a data access component with a 'flat' object model (say, ADODB) to invoke those views and procs with parameters and end up with a line count of 10K that are functionally equivalent and easier to read and maintain. So which is best: 50K or 10K? apples or oranges? Jamie. -- |
#19
|
|||
|
|||
Are there known issues with Vista and Acc2003
onedaywhen wrote:
That's a valid point against ADO if you are only interested in performance. Now think about data integrity: some database constraints (including primary keys) cannot be implemented with indexes and Validation Rules alone (big hint: table-level CHECK constraints). But that that's just two issues out of many so let's not do the ADO vs DAO thing again here and instead focus on the question in hand i.e. should one avoid a feature (ADP) merely because 'Micosoft support' no longer recommends it? Merely? How about the tons of things that suck about them? Most Access developers saw the folly of ADPs even when MS was encouraging their use. To say that they are not recommending them now "merely" because MS has stopped pushing them is a bit of a stretch. The attitude change from MS is simply a bit of validation to the arguments that have been there all along. -- Rick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com |
#20
|
|||
|
|||
Are there known issues with Vista and Acc2003
onedaywhen wrote:
That's a valid point against ADO if you are only interested in performance. Now think about data integrity: some database constraints (including primary keys) cannot be implemented with indexes and Validation Rules alone (big hint: table-level CHECK constraints). But that that's just two issues out of many so let's not do the ADO vs DAO thing again here and instead focus on the question in hand i.e. should one avoid a feature (ADP) merely because 'Micosoft support' no longer recommends it? Merely? How about the tons of things that suck about them? Most Access developers saw the folly of ADPs even when MS was encouraging their use. To say that they are not recommending them now "merely" because MS has stopped pushing them is a bit of a stretch. The attitude change from MS is simply a bit of validation to the arguments that have been there all along. -- Rick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com |
Thread Tools | |
Display Modes | |
|
|