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
|
|||
|
|||
Changing Query Defs in VBA
On Feb 7, 5:26 am, "Larry Linson" wrote:
You have a broad view of Access... I'm a broad-minded person ;-) IMNSHO, it does not "encompass" JET nor "encompass" ACE. It uses them as database engines, and those are the database engines it uses by default. However, it can also use Informix, or DB2, or Oracle as its database engine, but that doesn't make this an appropriate place for questions about using Informix with some other UI like PowerBuilder, nor Oracle with Oracle Forms, nor DB2 with Java. If someone has a question about their Jet database (e.g. Jet SQL DDL syntax) IMHO the Access groups are their best bet for an answer, regardless of 'front end', because most Access users (including Access MVPs) will have considerable experience of Jet because, as you say, it is their default data engine. I suggest the best outcome here is for us to agree to disagree. If the 'front end' in question is C# then the default database engine is SQL Server, hence Jet knowledge is scarcer in the C# or .NET framework groups (I occasionally see posts about OLEDB+Jet in the Access groups where the poster has been 'redirected' from the .NET languages groups). We seem wildly off-thread so I suggest the best outcome here is to agree to disagree (you could start a new thread). If so, please could you ask why ON UPDATE CASCADE, CREATE TEMPORARY TABLE and multiple-field NOT NULL constraints are mentioned in the Access Help but do not appear to actually be supported? because I don't have occasion to need them in what I do, my motivation to explore the subject is low. Given that, it is not a question that I would put to Microsoft as you have stated it. In summary, you seem to be saying, "I could but I won't." Fair enough Thanks for considering it, though. And apologies to the group for not resisting the oppotunity to go off-thread here myself. You can let Microsoft know of your dissatisfaction with the Help The source of my dissatisfaction is the absence of a specification for the Jet engine and I suspect the situation will never change (but I live in hope g). Jamie. -- |
#52
|
|||
|
|||
Changing Query Defs in VBA
"Larry Linson" wrote in
: One possibility would be that those SQL DDL statements were documented but then the functionality did not make it into the product, in which case, the best outcome you are likely to see would be a change to the Help text. Or it could be a case where the DDL is supported in ADO but not in DAO, as is the case with some data types that I forget. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#53
|
|||
|
|||
Changing Query Defs in VBA
"Jamie Collins" wrote
because I don't have occasion to need them in what I do, my motivation to explore the subject is low. Given that, it is not a question that I would put to Microsoft as you have stated it. In summary, you seem to be saying, "I could but I won't." Fair enough Thanks for considering it, though. In fact, I passed on your question in a private newsgroup for Access MVPs. One of my MVP colleagues confirmed that one of the examples in Help (about an item you mentioned) did not work. I suggested if any of the MVPs who read it had a response for you, they respond directly in the thread, which I identified. As none have responded here, so far, I can only suggest **again** that you use the facilities in Help to communicate with Microsoft. Unless I have have a specific question, have personally tested a reported error, validated that it fails, and my MVP colleagues have reproduced the error, I would not presume on my relationship with anyone at Microsoft. I do no work, in general, in DDL and little in ADO*, so I would have to invest more time and effort to pursue your issues than I am prepared to invest. And, I am not convinced that any but an infinitesimally small minority of Access users would ever use those features, so "wider applicability of an answer" is not an incentive, either. * Being an Access MVP does not require that one be, nor imply that one is, expert in every area of Access. It is a product with many, many facets, features, and capabilities, and it is unlikely that anyone is "expert in every area". From your discussions, I draw the conclusion that you use DDL to create databases and database objects because you do NOT use Access, but other UIs, even in database design. So, this would also fall beyond what I perceive to be appropriate questions for this newsgroup and I note that you have "agreed to disagree" on that issue. I find that there are rarely answers to "why" questions for any vendor's software -- they are often taken as accusations that the vendor deliberately did something wrong, whether or not that was the questioner's intent. You can let Microsoft know of your dissatisfaction with the Help The source of my dissatisfaction is the absence of a specification for the Jet engine and I suspect the situation will never change (but I live in hope g). In the past, books have been published that dealt with the Jet database engine. There is a good deal of documentation freely available from http://support.microsoft.com and http://msdn.microsoft.com, though I don't know if any of it will meet your criteria. In the meanwhile, my guess is that the obvious answer as to "why" those things are in Help and not supported is simply that "they are but are not". I have been privileged to meet some of the Help team at Microsoft, and am convinced that they do take into account the responses we can provide through the Help system. So it's possible, if you do offer a suggestion on improving the usability of Help, that it will result in a change. For your information, a quick search of newsgroups in the microsoft.public hierarchy showed 5 newsgroups related to VB and database, one related to VC and database, and one related to Visio database modeling. Larry Linson Microsoft Access MVP |
#54
|
|||
|
|||
Changing Query Defs in VBA
"David W. Fenton" wrote
Or it could be a case where the DDL is supported in ADO but not in DAO, as is the case with some data types that I forget. I was operating under the assumption that Jamie was discussing ADO. Larry |
#55
|
|||
|
|||
Changing Query Defs in VBA
On Feb 8, 1:22 am, "Larry Linson" wrote:
There's lots of interesting stuff in this thread. So long as no one minds that this has gone way OT, I'll pick up some of your points... Unless I have a specific question, have personally tested a reported error, validated that it fails, and my MVP colleagues have reproduced the error, I would not presume on my relationship with anyone at Microsoft. Don't worry about it, Larry. You've gone "above and beyond" already and I thank you again for your efforts. As none have responded here, so far, I can only suggest **again** that you use the facilities in Help to communicate with Microsoft. I have been privileged to meet some of the Help team at Microsoft, and am convinced that they do take into account the responses we can provide through the Help system. You are correct, of course. I _should_ do this more. Thing is, I've grown a little apathetic because I've given such feedback to Microsoft in this way on many, many occasions and it has never, to my knowledge, resulted in change. I guess there's an element of disbelief that I'm the only one who has spotted these apparent errors, have tried and failed to get them to work and have not bothered to report them to Microsoft; as you pointed out up thread, there's nothing special about me in that regard so I can only assume that countless others have reported the errors. The documentation has been recently revised for Access 2007 (e.g. text corrections to substitute 'Access SQL' for 'Jet SQL') and the Help still contains them. My conclusion is Microsoft are not bothered (I acknowledge there is no direct connection to the individuals - your friends - who comprise the team and the business demands imposed upon them) so neither am I. However, this is assuming they are indeed text errors in the help. You seem convinced but AFAIK there could still be alternative explanations e.g. these features exist in the engine but didn't make it into the release version ('commented-out'), they should be in the release version but are inadvertently crippled by bugs, etc. You may ask, 'Why would this matter?' Well, if it were a case of a simple bug fix then there is increased likelihood of them becoming working features in the product. Also, there's no point in troubling the 'documentation' team if the problem is the domain of the 'engine' team. The source of my dissatisfaction is the absence of a specification for the Jet engine and I suspect the situation will never change (but I live in hope g). I find that there are rarely answers to "why" questions for any vendor's software -- they are often taken as accusations that the vendor deliberately did something wrong, whether or not that was the questioner's intent. In the past, books have been published that dealt with the Jet database engine. There is a good deal of documentation freely available from http://support.microsoft.com and http://msdn.microsoft.com, though I don't know if any of it will meet your criteria. My ultimate question is a 'what' question: What is the Jet engine supposed to do? My criteria for judgement purposes would be the level of detail provided. To illustrate my point, I'll take ACE/Jet 4.0 table-level CHECK constraints. First off, you are probably thinking, "I don't use CHECK constraints, I don't need them and anyway they are 'ADO only' and I don't use ADO." From Access 2002 the CHECK syntax (like all other syntax previously only available to ADO) has been available via the Access UI while in ANSI-92 Query Mode so the 'Jamie is discussing ADO' line is, to use your term, a MMM (I prefer to dismiss the idea that it could be a deliberate red herring, though) because I am talking about ACE/Jet ANSI-92 Query Mode. Do you need CHECK constraints? That depends on you view, I suppose. I believe that every table should have a 'key' which I (and perhaps others) define as being a database constraint that prevents duplicate entitles. It is not always possible to implement such keys using the PRIMARY KEY or UNIQUE constraints available in ACE/Jet; the example I normally use, because it is a commonly encountered one, is the sequenced key in a valid-time state table a.k.a. history table, requiring several individual constraints including CHECKs to ensure no duplicate data for a given instant in time (see http:// groups.google.com/group/microsoft.public.access.forms/msg/ 04c3f233ba3336cc). Various Access articles (e.g. http://support.microsoft.com/kb/201888) and Jet articles (e.g. http://support.microsoft.com/kb/275561) mention it but I think anyone would conclude that there is not much available in the way of detail. The articles 'allude' to it being derived from the SQL-92 standard (for which Microsoft's preferred term is 'ANSI') but one thing we do know is that ACE/Jet's ANSI-92 Query Mode "conforms closely to the ANSI-92 Level 1 specification, but is not ANSI-92 Level 1 compliant" (http://office.microsoft.com/en-gb/access/ HP030704831033.aspx). Have you ever consulted the SQL-92 spec? (The Wikipedia stub has a link: http://en.wikipedia.org/wiki/SQL-92). Its detail is impressive. Here's a selective quote from the SQL-92 spec, 4.10 Integrity Constraints: "Every constraint is either deferrable or non-deferrable [we know ACE/Jet constraints are non-deferrable]... if a constraint is non-deferrable, then its constraint mode is always immediate...If the constraint mode is immediate, then the constraint is effectively checked at the end of each SQL-statement." I've demonstrated that ACE/Jet CHECK constraints are checked too early; on a row-by-row basis (http://groups.google.com/group/ microsoft.public.access/msg/8e3f2cf5f94e0b11); and on a table-by-table basis using a left-to-right order in the SQL statement (http:// groups.google.com/group/microsoft.public.access/msg/80f53c76fa01c832). So ACE/Jet CHECK constraints are non compliant with the SQL-92 standard. At this point, I don't know whether the ACE/Jet actual behaviour is by design because Microsoft haven't told us how it should work. My personal opinion is that it's a bug. There is certainly a lost potential in terms of utility i.e. without being able to defer a constraint until the end of a transaction I must instead DROP then re- CREATE the constraint within the transaction, resulting in a table lock (ouch!) Other constraints (e.g. foreign keys including referential actions) are checked on a SQL statement basis so it is at least an inconsistency. ACE/Jet CHECK constraints *must* be based on the SQL-92 standard because they allow subqueries (being a *full* SQL-92 feature), rather than being based on SQL Server (one of the motivations for developing ANSI-92 Query Mode) which does not support subqueries in CHECK constraints. I figure Microsoft did not strive for entry level SQL-92 for Jet because of *existing* functionality (e.g. the proprietary and unpredictable UPDATE..JOIN syntax: see http://groups.google.com/group/ microsoft.public.access/msg/d5f2641c3497ca4f) rather than new functionality. Put another way, why put in new functionality while *purposely* making it inconsistent with both the spec on which it is based (SQL-92), its 'big sister' product and the product's existing constraints? Again, the distinction between 'by design' and 'due to a bug' is relevant because a bug has more likelihood of being fixed. Until I know it is a bug I can't raise the issue with Microsoft (regardless of the likelihood of a response). So the starting point is for Microsoft to tell use the intention of the functionality. Obviously, the same can be applied to Jet functionality in general. I guess one advantage of declaring a product compliant with a particular level of a standard (e.g. for SQL Server, Microsoft claim entry level SQL-92 compliance) is that the vendor doesn't have to provide a detailed spec, because one has already been written for them, but a big disadvantage is that it reveals bugs! Being an Access MVP does not require that one be, nor imply that one is, expert in every area of Access. It is a product with many, many facets, features, and capabilities, and it is unlikely that anyone is "expert in every area". I don't remember saying or implying otherwise and I'm happy to agree your above statement. However, there seems to me to be a bit of a contradiction in what you are saying in this thread. You say Access "is a product with many, many facets, features, and capabilities" but you think Jet/ACE, it's default engine, is off-topic for the Access groups unless the Access UI is being used. I don't think many people would agree with you. We get many Jet-no-Access questions here due to the popular belief that 'Access database' equates to 'Jet database'. Microsoft has enjoyed blurring the distinction between the two: I'm sure I can find many Microsoft articles where the term 'Access database' has been used where Jet database' would be more correct (e.g. why is the odbc driver named 'Access' rather than 'Jet'?) For your information, a quick search of newsgroups in the microsoft.public hierarchy showed 5 newsgroups related to VB and database, one related to VC and database, and one related to Visio database modeling. As I keep repeating, there are no 'Jet as a backend' newsgroups and no 'Jet as a backend' Access MVPs and IMO there is a better chance of getting an answer to one's Jet-no-Access question from an Access MVP or in the Access groups than there is from, say, a .NET/C# MVP or a .NET/C# group. I don't see many Jet-no-Access posters being turned away nor do see you, Larry, admonishing anyone (other than me, perhaps) for answering their questions. I see all sorts of rubbish posted in the Access groups but the general approach is to ignore it (or respond politely) if it is not on-topic. Most Jet-no-Access topics get answered because IMO most people consider it on-topic. If you decided to go on a crusade against all the Jet-no-Access posters (rather than, say, just me), how would you determine Access is not involved? I'm pretty sure Access is bought for its database object management tools (as distinct from its RAD forms-based application development and runtime capabilities) i.e. some people prefer GUI tools to create database objects. If the poster promised faithfully their backend database is created and maintained using the Access UI, even if their 'front end' is not Access Forms, they have a commercial report writer, etc, would be that OK with you if they asked a question in the Access groups? I mean, they've bought their licence and they're using Access in the way it was designed so surely they can expect some support in the Access groups? If you were to enforce your "genuine Access users only, please" policy, what is the minimum criteria: at least one Access Form or Report, one table property that can only be created/utilised using the Access UI? I'm not sure how popular you'd be with Microsoft because I get the feeling they like to cross-sell their products e.g. Excel has the ability to consume 'Access' data and Microsoft likes it that way, so what's wrong with me pointing out that Access-only features (e.g. NZ(), Replace(), UDF, etc) will cripple their VIEW for use in MS Query via MS Excel or that implementing database constraints in an Access Form rather than in the database leaves their data integrity wide open to the MS Excel user who discovers they can execute INSERT/UPDATE/ DELETE statements from the MS Query SQL window? From your discussions, I draw the conclusion that you use DDL to create databases and database objects because you do NOT use Access, but other UIs, even in database design. You haven't quite got it spot on. I have numerous version of Access available to me and currently I have Access95, Access2000 and Access2007 (beta 2 I think) installed on virtual machines. Don't tell anyone this - I have a rep to protect g - but I do sometimes use the Access user interface to create databases and even to create tables and other database objects e.g. I used it the last week to create Validation Rules (for me the UI faster than writing code). The thing is, my interest lies in 'portability': no use leveraging functionality in one SQL product if there is no equivalent in another. This is how I came to SQL DDL: generally speaking, the Access/Jet-only functionality is unavailable as DDL and Access/Jet features that are portable are available as DDL. Another motivation is being able to post designs in the Access groups: alternative approaches are tend to be more verbose yet with less detail; I don't pick on individuals so here's the _most recent_ 'description' approach that caught my eye as lacking in detail: http:// groups.google.com/group/microsoft.public.access.tablesdbdesign/msg/ 6ff7a91ec2dfc30b. Yet more motivation is the desire to 'persist' (consider that 'mouse clicks' get lost) and document designs (consider that the parser interprets so SQL DDL coming out, in effect, would look different to the SQL DDL that went in, as it does with, say, SQL Server). Typical usage is answering a newsgroup post where I have to both create a design them 'reproduce' in plain text. Also consider my primary role is in database (backend) design and it is my personal approach to get the database tables (including constraints), views and procs up and running (i.e. ensuring data integrity while allowing effective CRUD abilities for entities) before anyone's 'front 'end' code gets to use them. It works well for me and, again, I figure I'm not special, so it could work well for others too. I use more than one database engine but Jet has some USPs; notables include subqueries in CHECK constraints and good cycle checking in DRI referential actions. Using OLE DB providers provides a quick way of switching between engines (I suspect that now Microsoft has given us a free OLE DB provider for ACE I'll be using the Access 2007 UI less) so it's no coincidence I'm more familiar with the ANSI-92 Query Mode flavour of Access/Jet SQL. So, this would also fall beyond what I perceive to be appropriate questions for this newsgroup and I note that you have "agreed to disagree" on that issue And I note that you have yet to. Jamie. -- |
#56
|
|||
|
|||
Changing Query Defs in VBA
Jamie Collins wrote:
Not really. Assuming we haven't gone too far OT (have to be careful, *I* get called names g) but I'm very wary of CLR in SQL Server. T- I'm not usually verbose but I feel that I need to respond in kind :-). I think I'll comment in a future post about CLR versus T-SQL functions. I've read the articles and though about your suggestions. The articles deal mostly with where security and data integrity occur for the data. I think that it's a good thing that the Access/Jet and SQL worlds are being forced to do some merging. Access/Jet users have been able to get by with using less formal methods than our SQL user counterparts. This is one of the reasons why I think your input is valuable. As someone who used to do most things using recordsets in VBA, I found doing the same things in SQL to be much more elegant yet less powerful. C.f.: http://groups.google.com/group/comp....c6295af8c00685 Consequently, I began more and more to accomplish things in SQL realizing that it is more scalable, yet to use VBA for the thorniest problems hoping that the VBA code would give me some clues about how to write equivalent SQL later. Having learned SQL from the Access/Jet side, I was constrained by the limitations of Access/Jet SQL when experimenting. Furthermore, Microsoft never took pains to reveal the existence of CHECK constraints. I think that the CHECK constraints are simply an awareness thing. No Access/Jet user seems to think they are a bad idea, but no one's been using them. I think they will be a great habit for Access/Jet users to develop. In one of our previous discussions: http://groups.google.com/group/micro...0488dffe168b09 I noted that the time history table approach will require too much maintenance/complexity in SQL for the average Access developer until the SQL-3 standards get implemented. Although I've had undergraduate and graduate courses in programming, my formal training is in applied mathematics and mechanical engineering. I think that is one of the reasons people can understand me :-). In mathematics and computer programming I have seen that formalism can be taken to extremes. Both engineering and mathematics have a formalism about how to know whether something is correct or not. Much engineering thought deals with intuition, testing and a kind of Socratic checklist that seems to parallel CHECK constraints. For instance, when using numerical methods for fluids problems a check is made on each discrete "differential" volume to make sure that basic engineering equations like conservation of mass still hold within the numerical method so that numerical instabilities can be detected or prevented. Like with CHECK constraints, I agree that formalism, per se, should not be discouraged. In practical situations I have to balance the requirements with how much formalism I allow noting that formalism usually increases the abstract level, and hence the complexity, of the application. I know that I need to increase continually the amount of formalism of my applications, but I also have to get my work done. I'll have to ease CHECK constraints into my work habits. I designed a SQLServer backend for an e-commerce app in 1999 and was fortunate enough to get by with slightly modified Access/Jet techniques. As the Access/Jet and SQL worlds continue to merge I hope to find a happy medium with methods that are a little more formal than what I currently use. Again, thanks for your help on this path. James A. Fortune |
#57
|
|||
|
|||
Changing Query Defs in VBA
Yours is a long and interesting reply.
I don't see many Jet-no-Access posters being turned away nor do see you, Larry, admonishing anyone (other than me, perhaps) for answering their questions. Please note that my objection to Jet-no-Access or ACCDB-no-Access issues or topics in the microsoft.public.access newsgroups is not with questions about them, as you imply -- no one is obligated to respond to them so we can ignore them if we wish, and I most often do. And, if that is the question that's asked, you don't find me admonishing you about answering it. (As with any post, I may well respond if I believe a response to be in error and/or misleading, no matter who posted the erroneous or misleading answer.) My objection is to responses that imply they could solve the poster's problem, but are in fact only remotely, if at all, related to the question that was about the Access-Jet or Access-ACDB environment. Unfortunately, you and I "cross words" over those because you repeatedly insert such topics into threads where they only a digression, confusing and misleading the poster or other participants. If you'd post those topics as original posts or questions, or in answer to questions about the environment to which they apply, you wouldn't be interfering with the purpose of the newsgroup to the extent that hijacking the threads does. And, perhaps to your surprise, you'd find that I really do leave the issue of "topicality" up to whoever at Microsoft is in charge of the microsoft.public hierarchy. (However, you'll find that many of us here will offer the suggestion to posters whose question is clearly off-topic that they'd stand a better chance of getting a useful answer elsewhere.) Thing is, I've grown a little apathetic because I've given such feedback to Microsoft in this way on many, many occasions and it has never, to my knowledge, resulted in change. Yes, it's not always easy to see the results, even when the feedback does "influence the future". You may rest assured that Microsoft gets "loud and clear" response from its MVP community when Help is not what we perceive to be "up to snuff", but the responses via the facilities of the Help system are in some Microsoft employees job performance "measurement" so they _will_ be read and evaluated. And, when the finite resources are expended on changing the Help engine (as they were in the past, from WinHelp to HTML Help) at the expense of content, it is very frustrating. There are many areas in which software vendors use that "finite resource" to address issues that are more likely to affect what they consider their "mainstream customers" for the product, rather than pursuing a "purist" ideal for people who aren't in that category. It can also be very frustrating to discover that the vendor's idea of who are the "mainstream customers" is different from yours. The fact that you can see that their emphasis and lack of emphasis makes perfect sense from their point of view doesn't make it any less frustrating. I have, unfortunately, had that experience from time to time since before there were any microcomputers. My ultimate question is a 'what' question: What is the Jet engine supposed to do? My criteria for judge- ment purposes would be the level of detail provided. I agree that it would be nice to have a detailed specification of software functionality, but I know that is rare, indeed, for such to be published for commercial software. And that has been the case since the beginning of the "computer business". It is even rarer for software for which the common perception is "nice little desktop database". Standards are good, and there may be some implementation that truly conforms to the standards. Notice I use the singular, because I'm reasonably sure that I've never encountered any commercial software that did. It's just too tempting for vendors or implementers to add their own "flavor" to their product. The documentation has been recently revised for Access 2007 (e.g. text corrections to substitute 'Access SQL' for 'Jet SQL') and the Help still contains them. Ah, yes, the power of "global text find-and-replace". I once had an acquaintance whose first name was "August", but in a revision to his local telephone book, he became "September". But, now, the designation of "Access database" will not necessarily be a misnomer. Now that the Access team "inherited" Jet from the separate group who previously "owned" it in Microsoft, and derived ACCDB from it, there is a real, genuine "Access database." The thing is, my interest lies in 'portability': no use leveraging functionality in one SQL product if there is no equivalent in another. But, "portability" is rarely the answer to any question in this newsgroup, and this isn't the venue to campaign for it or champion it. In fact, for most of the database upscaling in which I've been involved, portability was not a significant issue; it's an issue primarily in the enterprise environment, in which there may be a number of different "front ends" (UI or otherwise) to the same database. But, no surprise, the number of less-than-enterprise implementations vastly outnumbers the enterprise implementations. And, for most of the posters here, to invest time and energy in portability is expensive, fruitless folly. It is important to you, it is important to others, and has even been important to me at times (but because of my changing client base, it is less important to me now than before). And, I think we have long-since exhausted the usefulness of continuing this admittedly-far-off-topic meandering. I wish you well. I hope you'll consider moving the no-Access stuff to threads where it clearly applies, or to initiate new threads. For this thread, I am inclined to "give you the last word". Regards, Larry |
#58
|
|||
|
|||
Changing Query Defs in VBA
On Feb 8, 11:23 pm, "Larry Linson" wrote:
If you'd post those topics as original posts or questions, or in answer to questions about the environment to which they apply, you wouldn't be interfering with the purpose of the newsgroup to the extent that hijacking the threads does. And, perhaps to your surprise, you'd find that I really do leave the issue of "topicality" up to whoever at Microsoft is in charge of the microsoft.public hierarchy. "portability" is rarely the answer to any question in this newsgroup, and this isn't the venue to campaign for it or champion it. for most of the posters here, to invest time and energy in portability is expensive, fruitless folly. It is important to you, it is important to others, and has even been important to me at times (but because of my changing client base, it is less important to me now than before). Sincere thanks for taking the time to detail you objections. I think I have understood them but, alas, I still do not agree. I continue to consider portability to be on topic and continue to consider the Access groups the best newsgroups for questions, answers and discussions about the Jet/ACE engine. You tell me it is not up to you to determine 'topicality' in the Access groups and I take that on good faith. You know, I really don't feel I've received much negative feedback on these issues, yourself included. As for a way forward, I can only suggest that in future you raise any objections to you may have to my posts to the threads in question and in a timely manner; I think this thread has demonstrated that trying to deal with generalisations after the fact, rather than specifics at the time, is very time consuming and doesn't serve the interests of the group. Or perhaps you'll leave me alone; if it helps, think of my posts as expensive, fruitless folly in terms of the time and effort I put in. As Microsoft's rules of conduct require, please avoid personal attacks and slurs in your replies to me. I wish you well, too. Jamie. -- |
Thread Tools | |
Display Modes | |
|
|