A Microsoft Office (Excel, Word) forum. OfficeFrustration

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.

Go Back   Home » OfficeFrustration forum » Microsoft Access » General Discussion
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Changing Query Defs in VBA



 
 
Thread Tools Display Modes
  #51  
Old February 7th, 2007, 10:01 AM posted to microsoft.public.access
Jamie Collins
external usenet poster
 
Posts: 1,705
Default 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  
Old February 7th, 2007, 04:40 PM posted to microsoft.public.access
David W. Fenton
external usenet poster
 
Posts: 3,373
Default 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  
Old February 8th, 2007, 02:22 AM posted to microsoft.public.access
Larry Linson
external usenet poster
 
Posts: 3,112
Default 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  
Old February 8th, 2007, 02:27 AM posted to microsoft.public.access
Larry Linson
external usenet poster
 
Posts: 3,112
Default 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  
Old February 8th, 2007, 01:57 PM posted to microsoft.public.access
Jamie Collins
external usenet poster
 
Posts: 1,705
Default 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  
Old February 8th, 2007, 08:17 PM posted to microsoft.public.access
James A. Fortune
external usenet poster
 
Posts: 903
Default 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  
Old February 9th, 2007, 12:23 AM posted to microsoft.public.access
Larry Linson
external usenet poster
 
Posts: 3,112
Default 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  
Old February 9th, 2007, 05:28 PM posted to microsoft.public.access
Jamie Collins
external usenet poster
 
Posts: 1,705
Default 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 02:37 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.