Ryan <Mindflux98 (AT) gNOSPAMPLEASEmail (DOT) com> wrote in
news:ifba84$f4b$1 (AT) news (DOT) eternal-september.org:

How recent is the documentation that suggested that? I think it very
likely it's something that dates from the "ADO wars" period, when MS
was incorrectly pushing ADO for use with Access.

DAO is not deprecated. It is in live development, with new versions
coming out with each new version of ACE/Jet.

That contrasts to Classic ADO, which has not been updated for a long
time, and never will be (because it has been replaced with ADO.NET,
which does not work with Access, and likely never will, at least not
until Access is .NET-compatible).

[]

You mean you're writing a QueryDef each time you use it? Likely
completely unnecessary. Post your code and maybe somebody can
suggest a fix that doesn't require rewriting and saving it each
time.

Do you know about temporary QueryDefs? If you supply no name when
you open it, it will be discarded when you close it (I forget the
details -- it's something I have never had any cause to do). I do
believe that temporary QueryDefs do still contribute to front-end
bloat, but not very much.

I'd still want to use some other approach if it were my app.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

On Thu, 23 Dec 2010 09:02:43 -0600, Ryan
<Mindflux98 (AT) gNOSPAMPLEASEmail (DOT) com> wrote:

Q&D (Quick & Dirty) change the macro security to low (or any other
setting via Tools | Macro | Security).

Registry -

Root=Local Machine
Key=SOFTWARE\Microsoft\Jet\4.0\Engines
Name=SandBoxMode
Value=#00000002 (dword)

Root=Local Machine
Key=Software\Microsoft\Office\11.0\Access\Security
Name=Level
Value=#00000001 (dword)

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

On 12/27/10 6:56 PM, David-W-Fenton wrote:
When I googled the error code a KB article came up about how ODBCDirect
was depreciated and to re-write the 'offending' code in ADO.
DAO Workspaces are, DAO itself may not be. (DAO Workspaces are called
ODBCDirect by some documentation)



Yes I'm using a temporary querydef (no name assigned)

Like what? As I said, the 'passthrough' queries are stored in a table
by name and run order with the appropriate select/delete/append/update
statements so I have a loop that goes through them depending on how the
function is called.

Now that function uses a temporary qdf instead of the DAO workspace,
which AFAIK was just used to establish a connection to the SQL server
via DSN with the UID/PWD specified at logon time.

On 12/27/10 6:56 PM, David-W-Fenton wrote:
Here's the code.

The function SetODBC basically grabs the DSN/Server name/etc out of a
local table to set up the connection (seen on line 07)

http://pastebin.ca/2031070


That code will expire in a week. I don't want it lingering out since
it's not code originally written by me.

Ryan wrote:
If you can see the menu or toolbar when using the runtime then it is already
a custom one. Built in menus and toolbars are not available in the runtime.
All you should have to do is specify the custom menu as the application menu
in Tools - Startup.

I know it's a bit counter-intuitive, but even though built in menus are not
available in the runtime you still have to explicitly disable them in the
Startup options if you don't want to see a ribbon in Access 2007 and 2010.

On 12/28/10 7:27 AM, Rick Brandt wrote:
'too tall' and covering application buttons.

I changed the shortcut bar from (default) to the name of the custom bar.
So I guess this isn't solving my issue with it's height.

<HIGHLY OPINIONATED COMMENTS>
I remember being told as part of the pre-release "sales pitch" for The
Ribbon, that it "doesn't really take all that much screen 'real estate' --
it's less than three toolbars". (Try as I might, I could not remember a
single Access database application I'd created since Jan. 1993 that had
stacked even two toolbars at the top of the screen. It then dawned on me
that The Ribbon was only slightly less than 3 toolbars in height, and that
their 'sales pitch' was just another case of 'smoke and mirrors' misleading
marketing.)

The people who came up with The Ribbon as a "fix" for Word's cluttered menus
and the Mighty Microsoft Marketing and Management Machine who were gulled
into backing it for all of Office did, IMNSHO, the greatest disservice to
Microsoft of any group I can remember. (A possible exception would be
whoever made the decision to ditch Visual Basic 7.0 and go to VB.NET.)
</HIGHLY OPINIONATED COMMENTS>

Larry

P.S. There are those, I've heard, who translate "HIGHLY OPINIONATED
COMMENTS" to mean "RANT".

"Ryan" <Mindflux98 (AT) gNOSPAMPLEASEmail (DOT) com> wrote

?"Access Developer" wrote in message
news:8num33F92iU1 (AT) mid (DOT) individual.net...

I never really saw or heard that sales pitch.
And, I NEVER heard anyone claim that people use 3+ stacked tools bars in
access.

I for sure seen the case that options were growing and something had to be
done.

The use case that I always seen is that by using MORE screen space you can
improve the UI.

In fact, here is a quote from the ribbon document on MSDN. It is a good
document:

http://msdn.microsoft.com/en-us/library/cc872782.aspx

<quote>
Menu bars and toolbars are primarily designed to be space efficient. To
provide their benefits, ribbons may consume more vertical space, being
roughly the equivalent of a menu bar plus three rows of toolbars. Being that
few programs have three or more rows of toolbars, ribbons usually consume
more space than traditional UIs for commands.
</quote>

So, in fact the above document on ribbons is claiming that ribbons use more
space. I see NO attempt to mislead people about this issue.

The above FLAT OUT says that a ribbon will use more space then a menu bar.

More from the above doc:

<quote>
<Ribbons> are Modal but not hierarchical. Menu bars scale by creating a
hierarchy of commands. Menus with many items can use one or more levels of
submenus to provide more commands.
Ribbon commands require more space than toolbar commands, so they use tabs
to scale.
</quote>

Again a no sugar coating of this issue. I not here to sell anyone on the
ribbon, but I much disagree that some type of smoke and mirrors was being
used here?

I seen NOTHING that claims ribbons use less space then menu bars or even
what the typical user setup was in the past was 3 toolbars stacked high. I
have seen the case made that the UI was becoming too cramped.

However, what is nice is that you CAN minimize the ribbon. And even when you
do this you are NOT using a hierarchy of commands. You still going to be
using less clicks then a menu system.

The real simple use case for the ribbon is that we now have more screen
space, and office products (including access) has seen an MASSIVE increase
in options, even since 2003.

The screen size is the real issue here.

In the year 2000, 56% of monitors were 800 x 600.

Want to take a guess today what % of monitors use 800 x 600 today?

Why it is 1% Just 1% today!

In fact 1024x768 as ONE year ago was ONLY 20%.

Fully 76% of monitors now are GREATER THEN 1024 x 768.

What this means is monitors in terms of pixels has MORE then doubled in 10
years. I mean as I noted even going from access 2003 to 2010, the number of
properties for a control such as a button has gone from being less then two
pages of printout to now OVER 5 pages of just properties!

their 'sales pitch' was just another case of 'smoke and mirrors' misleading
marketing.)

I respectively disagree. You have quote me where this type of misleading
occurred. The documents I seen CLEARLY states that ribbons uses more space.

it is quite clear that the ribbon does use more space. However you GAIN
benefits for using that additional space and we have FAR more space today.

And, when you minimize the ribbon, you usually wind up with MORE space then
a typical menu bar + tool bar.

And, even when you do minimize the ribbon, you still gain a menu system in
which you not using a hierarchy to choose options and you going to use less
clicks in most cases.

A ribbon command is direct if invoked with a single click (that is, without
navigating through menus) and immediate if it takes effect immediately (that
is, without dialog boxes to gather additional input). Menu bar commands are
almost always indirect and often not immediate

At the end of the day, menu bars go back to the mid 1980's and they simply
just don't make a lot of sense anymore. Those old products had less then 300
options today even access has doubled or tripled the number of options. And
menu bars do not work well in touch screens (which again we see as a major
trend in our industry).

Toss in web stuff, and the UI even in access has been stressed to the max.

Even without web stuff, simple additions like the new control anchoring in
access has 9 NEW options. Where are all these options going to go?
We cannot just keep pilling this stuff into more menus.

So, yes, the ribbon does use more space, and the result is a increased ease
of use

So, I really never felt I was being mislead on this space use issue.

Perhaps others here received a different message, but in just about all
cases in the ribbon pitch, it was an issue that menus have been stretched to
the limit and had become too cluttered up. We needed a change here.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com

Ryan <Mindflux98 (AT) gNOSPAMPLEASEmail (DOT) com> wrote in
news:ifbi9o$ate$1 (AT) news (DOT) eternal-september.org:

The term "deprecate" was thrown around a lot in the period between
1999 and 2005 in regard to lots of Access-related technologies. My
bet is that the articles you got were not Access-related, but
designed for programmers using MS's programming tools, Visual
Studio, .NET, etc., for which the role of Jet/ACE and ODBC were very
different in comparison to Access.

The issue for me is not that ODBCDirect was deprecated (MS clearly
abandoned it by taking it out of Access, of course), but what was
recommended for replacing it. Classic ADO is not a viable technology
any longer, as it is just as deprecated (in favor of ADO.NET) for
MS's programming tools as ODBCDirect.

Of course, if you didn't witness the farce of the "ADO wars" in
regard to Access, you wouldn't get any of these nuances.

I don't know what the term "DAO Workspaces" refers to. Jet/ACE has
workspaces, and those can be manipulated via DAO. I don't believe
there is anything specific to DAO and Workspaces that is deprecated,
except for ODBCDirect workspaces. But those are deprecated because
ODBCDirect is deprecated, not because DAO is.

And, of course, in the context of MS's programming tools, DAO was
being deprecated as well. Until c. 2005, it was de facto deprecated
for Access, but MS finally figured out how wrongheaded that was and
changed course.

Again, it is difficult for those who didn't witness the whole
farcical drama to appreciate the ins and outs of all of this, so
there's little way for you to know, but the fact is, whatever those
documents say, DAO is not deprecated, nor any part of its feature
set.

[]

You can use a connect string within a SQL statement, too.

I don't understand your description of what you're doing so can't
really recommend an approach, but you should determine if a
passthrough is actually required. If it isn't, then you won't need a
QueryDef at all, temporary or not.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

Ryan <Mindflux98 (AT) gNOSPAMPLEASEmail (DOT) com> wrote in
news:ifbjn7$aol$1 (AT) news (DOT) eternal-september.org:

It looks to me like you are creating a QueryDef in a separate
workspace in order to execute the SQL statements stored in the
table. I don't see that you're defining the QueryDef as a
passthrough, so I don't know why you can't just execute the SQL
without a temporary QueryDef, nor even with a special workspace. I
don't know the content of the SQL statements and if they use linked
table names or if they refer to tables not available in your Access
front end. If they *are* available, then there's no need for the
workspace. If they aren't, that allows you to open a workspace with
a connection to an ODBC data source and then execute the SQL against
that ODBC data source.

So far as I can tell, there is no need to execute a QueryDef. It
seems to me that this:

qdf.SQL = rst!SQLstr
qdf.Execute

....could be replaced with:

Set db = DBEngine.OpenDatabase([ODBC connect string])
db.Execute rst!SQLstr

The reason for my saying this is that you're creating your QueryDef
off of CurrentDB which means it's executing in the context of your
local database (along with the ODBC connect string), so that means
passthrough is not really an issue.

I don't know the syntax for opening a database connection with an
ODBC connect string, but I doubt it's complicated.

So, from what I can tell, and from what I know (which is limited,
since I never do anything like this), it seems to me you absolutely
do not need the temporary QueryDef -- you just execute the SQL
directly from a database connection to the ODBC data source.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/