Operation Must Use An Updateable Query!? - NOT Permissions - CrossTab!!??

David;

many TX for your reply - I was unaware of an SQL support updates for
access...
I'll have to check that out - even though I doubt it'll fix this issue,
as you say, it may help elseware....

Bob

David W. Fenton wrote:
"Bob" wrote in
ups.com:

This is about as brain-dead, as anything microsoft has ever done;
and they've sure done plenty. Can't tell you how many times their
idiosy has ticked me off.

Well, pre-Access 97, a lot of these things worked, but were
completely inconsistent with every other SQL dialect. With A97/Jet
3.5, Microsoft tightened up the join and updatability rules to be
more consistent with other flavors of SQL, which is probably
something that was required in the push to make Access interoperable
with SQL Server.

Then there's SQL 92 support in A2K and later. I doubt it would solve
the problem easily, but it might provide other solutions to the
problem of unupdatability.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

TX again, David;

I agree with your suggestion; and taken with someone else's idea to
have the temp table in a totally separate db, resolves all my
compacting concerns....

Bob

David W. Fenton wrote:
"Bob" wrote in
oups.com:

Although dlookup is about as cycle intensive as it gets, I think
it's still better than constantly re-creating, and compacting huge
tables...

It's not.

Temp tables are going to be *much* faster. If it's a regular
operation, just keep a copy of the empty temp database and copy over
it when your app exits. That way you have a clean copy of the temp
database every time you start your app, and never have to compact
it.

Others say it's quick to recreate the temp table in code, once the
code is written. Me, I've never taken the time to write such code,
so find it easier to run a MakeTable query, then edit the resulting
table to have appropriate indexing, then empty it out, copy it into
the temp database and compact it.

I was surprised to discover that the time it takes to write to the
temp table is not greater than the alternatives that use all memory.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Users who want to get their fingers a little dirty can do so in an MDE, if
that means creating queries, which is about all users should be turned loose
to do. Even then, you have the issue of preserving queries created by users
if you replace the MDE with a new release.

Do your users want to create forms and reports?

Rick-

they do create reports, and rarely forms; also this isn't mission
critical data, so I don't need the protection / restrictions of the mde
- although I didn't know that you could create/save queries in an mde -
I thought it didn't let you do anything [of a development nature]....

Bob

Rick Wannall wrote:
Users who want to get their fingers a little dirty can do so in an MDE, if
that means creating queries, which is about all users should be turned loose
to do. Even then, you have the issue of preserving queries created by users
if you replace the MDE with a new release.

Do your users want to create forms and reports?

"Bob" wrote in
ups.com:

although, I will partially defend dbahooker (certainly not the
way he communicates it), in that on SEVERAL occasions, I have had
an mdb database go corrupt on me in some very strange ways -
beyond the point of repair (in fact, I couldn't even import my
work into a clean database), and I lost DAYS of work in 1 such
case. Whenever I work with mdb's I ALWAYS make a new copy of the
database before I open it because of this experience.

I have never seen an MDB corrupted beyond the ability of Peter
Miller to retrieve it. Of course, I've only once had an MDB that *I*
couldn't recover, so that's not many times.

If you encounter corruption on a regular basis, then I'd say you're
doing something wrong.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

I wouldn't say it happens on a regular basis, considering how often I
work in the environment, it's very rare. But it only takes 1 bad
experience to sour / caution you forever-more ....

Only that 1 time was I unable to repair/recover it; and it that 1 case,
PM wouldn't have been able to either.... it was VERY strange. Not even
sure if I didn't have a momentary [hardware] issue with memory....

David W. Fenton wrote:
"Bob" wrote in
ups.com:

although, I will partially defend dbahooker (certainly not the
way he communicates it), in that on SEVERAL occasions, I have had
an mdb database go corrupt on me in some very strange ways -
beyond the point of repair (in fact, I couldn't even import my
work into a clean database), and I lost DAYS of work in 1 such
case. Whenever I work with mdb's I ALWAYS make a new copy of the
database before I open it because of this experience.

I have never seen an MDB corrupted beyond the ability of Peter
Miller to retrieve it. Of course, I've only once had an MDB that *I*
couldn't recover, so that's not many times.

If you encounter corruption on a regular basis, then I'd say you're
doing something wrong.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

"Bob" wrote in
oups.com:

Only that 1 time was I unable to repair/recover it; and it that 1
case, PM wouldn't have been able to either.... it was VERY
strange. Not even sure if I didn't have a momentary [hardware]
issue with memory....

How do you know he couldn't? Do you have the tools to explore the
internal Jet file structure and the knowledge of it to be able to
say that data was not recoverable? Peter does have those tools and
that knowledge, having developed them himself over the years. I
would never presume to guess whether or not a corrupted MDB is
recoverable or not, given that I have no evidence or knowledge that
gives me a chance of making any kind of judgment of just how corrupt
it is internally.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

David;

Of course, you are correct; I cannot say that definitively. Though I
can say it with a great deal of confidence. I examinded it with a hex
editor, and found huge area's of severe corruption. It was as though
the "framework" was still in place, but the innerd's with all the
important stuff was gone. I would analogize it with having a hard disk
with partition table, and directory structure all intact, and you could
view the directory; but None of the files had any data what-so-ever (if
you've ever done intimate work with fat32, you know what I mean).

In any case, my comment wasn't meant as a criticism of Peter in any
way, just a relative gauge of the state of the mdb.

Bob

David W. Fenton wrote:
"Bob" wrote in
oups.com:

Only that 1 time was I unable to repair/recover it; and it that 1
case, PM wouldn't have been able to either.... it was VERY
strange. Not even sure if I didn't have a momentary [hardware]
issue with memory....

How do you know he couldn't? Do you have the tools to explore the
internal Jet file structure and the knowledge of it to be able to
say that data was not recoverable? Peter does have those tools and
that knowledge, having developed them himself over the years. I
would never presume to guess whether or not a corrupted MDB is
recoverable or not, given that I have no evidence or knowledge that
gives me a chance of making any kind of judgment of just how corrupt
it is internally.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/