Opinion on Access 2007

[Allen Browne]

If you are looking for opinon on what's useful in Access 2007, there's a new
article at:
http://allenbrowne.com/Access2007.html

Covers what's good (useful features), what's mixed (good and bad), what's
gone (features removed), what's fixed (old issues solved), what's broken
(new bugs), configuration, compatibility, should you buy, and links.

It is opinion, so you may disagree, but hopefully it's an informative
summary.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

[Sylvain Lafontaine]

To my knowledge, ADP have not been removed from Access 2007; however, it's
appears that they are now totally screwed in term of speed. .

I have done all of my tests with the Beta version and I must repeat them
with the RTM to be sure; however, some messages that I've read in the
newsgroups share the same conclusion. See for example:

http://groups.google.ca/group/micros...5419790b476f53

(Short story on my previous tests with the beta version: when running in a
virtual machine with 256Megs of allocated memory, I had to kill the whole
job to regain control of my PC and while running it with 512 Megs allocated,
it was a slow crawl. Profiling on the SQL-Server showed that the cause was
an incredible amount of queries made about the properties of objects on the
SQL-Server and that these queries was repeated each time the mouse was moved
from field to field and even inside a field in the case with 256 Megs of
memory allocated. No problem at all when running a MDB file in the same
VM.)

So you should move the ADP feature from the What's gone section to the
Totally Screwed section.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Allen Browne" <Al*********@SeeSig.invalidwrote in message
news:45***********************@per-qv1-newsreader-01.iinet.net.au...

If you are looking for opinon on what's useful in Access 2007, there's a
new article at:
http://allenbrowne.com/Access2007.html

Covers what's good (useful features), what's mixed (good and bad), what's
gone (features removed), what's fixed (old issues solved), what's broken
(new bugs), configuration, compatibility, should you buy, and links.

It is opinion, so you may disagree, but hopefully it's an informative
summary.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

[Lyle Fairfield]

Sylvain Lafontaine (fill the blanks, no spam please) wrote:

To my knowledge, ADP have not been removed from Access 2007; however, it's
appears that they are now totally screwed in term of speed. .

It's not so bad if you want to have breakfast while things load.

[David W. Fenton]

"Allen Browne" <Al*********@SeeSig.invalidwrote in
news:45***********************@per-qv1-newsreader-01.iinet.net.au:

If you are looking for opinon on what's useful in Access 2007,
there's a new article at:
http://allenbrowne.com/Access2007.html

Covers what's good (useful features), what's mixed (good and bad),
what's gone (features removed), what's fixed (old issues solved),
what's broken (new bugs), configuration, compatibility, should you
buy, and links.

It is opinion, so you may disagree, but hopefully it's an
informative summary.

Great article, Allen -- I really appreciate the work you've put into
preparing it.

Of coures, I have questions! :)

1. rich text: is the HTML *good* HTML, or the usual trashy, awful MS
stuff, with complex and idiosyncratic CSS? Is the HTML controllable?

2. minor spelling hint: under the embedded macros item, you mean
"deprecate" instead of "depreciate". Same for the big
"compatibility" section at the end.

3. the "features removed" section: I still object to the way people
are treating this. Security and Replication and ADPs have *not*
been removed from Access -- they were just omitted from the new
database format. Unless you're a moron, you won't just automatically
start using the new database format, right? What you mean is
"removed from new database format".

4. continuing from #3: In regard to replication, saying "Use
attached tables, connected to a database that has replication" is
rather misleading, as that's the way replication should have been
used in previous versions of Access, too, since only tables should
be replicated. I think it's misleading on all three of these issues
to not explicitly say that if you use MDB/ADB format you continue to
have all the functionality of previous versions of Access (it's only
DAPs that have actually been removed and can't be created in A2K7,
if I understand correctly).

5. Autofill: that was an A2K and later feature, so doesn't apply to
all previous versions (significant numbers of developers still do
lots of work in A97, and I barely remember the Autofill feature,
since I don't do too much data editing in table view in A2K and
later).

6. Imports: have that made it work better for Excel? That is, can
you now control the data types better than before, instead of having
to make sure the spreadsheet is absolutely properly formatted before
the import?

7. Compatibility Issues: is that an issue in converted MDBs as well
as in new ACCDBs?

8. Should I Buy section: I think that new users ought not buy it
unless they have no outside dependencies. That is, they aren't going
to share data with other users and don't have any existing
applications with a developer working on them. I just think an
unqualified "YES" is way too optimistic. Of course, I guess I'm
thinking more in terms of your second category. I still think the
first category oughn't be an unqualified affirmative, but a MAYBE. I
also just don't believe in the "learn it for the future" advice, as
that was the advice everyone gave for ADO when it was introduced in
Access. I didn't learn it, and, well, I have no regrets on that,
since Microsoft wised up and it's now deprecated in Access.

Overall, from what you've written, it seems to me that A2K7 is a
disaster similar to A95 -- much worse than A2K.

But, again, thanks very much -- I'll be using your article to try to
steer any of my clients away from buying A2K7.

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

[Lyle Fairfield]

David W. Fenton wrote:

I'll be using your article to try to
steer any of my clients away from buying A2K7.

You David? You're going to try to steer your clients away from buying
A2K7? Who would have guessed that?

[Rick Brandt]

David W. Fenton wrote:

"Allen Browne" <Al*********@SeeSig.invalidwrote in
news:45***********************@per-qv1-newsreader-01.iinet.net.au:

>If you are looking for opinon on what's useful in Access 2007,
there's a new article at:
http://allenbrowne.com/Access2007.html

Covers what's good (useful features), what's mixed (good and bad),
what's gone (features removed), what's fixed (old issues solved),
what's broken (new bugs), configuration, compatibility, should you
buy, and links.

It is opinion, so you may disagree, but hopefully it's an
informative summary.

Great article, Allen -- I really appreciate the work you've put into
preparing it.

Of coures, I have questions! :)

1. rich text: is the HTML *good* HTML, or the usual trashy, awful MS
stuff, with complex and idiosyncratic CSS? Is the HTML controllable?

I personally believe that this will be the cause of a huge number of
questions in these groups when used by people who don't understand what is
happening in the background. There are two major caveats to the Rich Text
(html) capability.

1) You are pretty much designating that no other application will interact
with the data in your field because no other app is going to be able to
properly display the text as stored.

2) From what I can tell you lose the ability in most cases to search the
data effectively. If you store "Some sample text" and make the word
"sample" display in red or bold or whatever then the following query will
not find it...

SELECT *
FROM TableName
WHERE FieldName = "Some sample text"

....because "Some sample text" is NOT what the table actually has stored in
it. It's going to be just like the lookup field problem. I would also
expect there will also be issues with trying to count characters, sorting on
the first 255 characters, parsing, etc..

I do think it's a nice feature, but as with many other things MS has done to
Access they are just foisting it on the unwashed masses who are not going to
understand all of the gotchas associated with it.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Allen Browne]

Thank you Sylvain.

You are correct. ADPs are still possible, so that line has been removed.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message
news:ug**************@TK2MSFTNGP02.phx.gbl...

To my knowledge, ADP have not been removed from Access 2007; however, it's
appears that they are now totally screwed in term of speed. .

I have done all of my tests with the Beta version and I must repeat them
with the RTM to be sure; however, some messages that I've read in the
newsgroups share the same conclusion. See for example:

http://groups.google.ca/group/micros...5419790b476f53

(Short story on my previous tests with the beta version: when running in a
virtual machine with 256Megs of allocated memory, I had to kill the whole
job to regain control of my PC and while running it with 512 Megs
allocated, it was a slow crawl. Profiling on the SQL-Server showed that
the cause was an incredible amount of queries made about the properties of
objects on the SQL-Server and that these queries was repeated each time
the mouse was moved from field to field and even inside a field in the
case with 256 Megs of memory allocated. No problem at all when running a
MDB file in the same VM.)

So you should move the ADP feature from the What's gone section to the
Totally Screwed section.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Allen Browne" <Al*********@SeeSig.invalidwrote in message
news:45***********************@per-qv1-newsreader-01.iinet.net.au...

>If you are looking for opinon on what's useful in Access 2007, there's a
new article at:
http://allenbrowne.com/Access2007.html

Covers what's good (useful features), what's mixed (good and bad), what's
gone (features removed), what's fixed (old issues solved), what's broken
(new bugs), configuration, compatibility, should you buy, and links.

It is opinion, so you may disagree, but hopefully it's an informative
summary.

[Lyle Fairfield]

Allen Browne wrote:

Thank you Sylvain.

You are correct. ADPs are still possible, so that line has been removed.

Possible = Open?

or

Possible = Create?

and

are DAPs the same?

[Smartin]

Allen Browne wrote:

If you are looking for opinon on what's useful in Access 2007, there's a new
article at:
http://allenbrowne.com/Access2007.html

Covers what's good (useful features), what's mixed (good and bad), what's
gone (features removed), what's fixed (old issues solved), what's broken
(new bugs), configuration, compatibility, should you buy, and links.

It is opinion, so you may disagree, but hopefully it's an informative
summary.

Great analysis and write up, Allen. Thanks for your hard work on this!

--
Smartin

[Allen Browne]

Thanks for your comments, David.
Responses embedded.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...

"Allen Browne" <Al*********@SeeSig.invalidwrote in
news:45***********************@per-qv1-newsreader-01.iinet.net.au:

>If you are looking for opinon on what's useful in Access 2007,
there's a new article at:
http://allenbrowne.com/Access2007.html

Covers what's good (useful features), what's mixed (good and bad),
what's gone (features removed), what's fixed (old issues solved),
what's broken (new bugs), configuration, compatibility, should you
buy, and links.

It is opinion, so you may disagree, but hopefully it's an
informative summary.

Great article, Allen -- I really appreciate the work you've put into
preparing it.

Of coures, I have questions! :)

1. rich text: is the HTML *good* HTML, or the usual trashy, awful MS
stuff, with complex and idiosyncratic CSS? Is the HTML controllable?

It's quite basic HTML, used to format the text, not a full HTML page.
Therefore there is no header, no CSS. Use Div for paragraphs. Not
particularly nice, but it works.

It does mean you can format text within a text box on a report, e.g.:
="Thank you, <B>" & [FirstName] & "</B>, for your suggestion."

2. minor spelling hint: under the embedded macros item, you mean
"deprecate" instead of "depreciate". Same for the big
"compatibility" section at the end.

Thanks, fixed.

3. the "features removed" section: I still object to the way people
are treating this. Security and Replication and ADPs have *not*
been removed from Access -- they were just omitted from the new
database format. Unless you're a moron, you won't just automatically
start using the new database format, right? What you mean is
"removed from new database format".

Wording adjusted.

4. continuing from #3: In regard to replication, saying "Use
attached tables, connected to a database that has replication" is
rather misleading, as that's the way replication should have been
used in previous versions of Access, too, since only tables should
be replicated. I think it's misleading on all three of these issues
to not explicitly say that if you use MDB/ADB format you continue to
have all the functionality of previous versions of Access (it's only
DAPs that have actually been removed and can't be created in A2K7,
if I understand correctly).

Ditto.

5. Autofill: that was an A2K and later feature, so doesn't apply to
all previous versions (significant numbers of developers still do
lots of work in A97, and I barely remember the Autofill feature,
since I don't do too much data editing in table view in A2K and
later).

Correct: A97 did not have that annoyance.

6. Imports: have that made it work better for Excel? That is, can
you now control the data types better than before, instead of having
to make sure the spreadsheet is absolutely properly formatted before
the import?

I haven't experimented extensively with this, but the Import wiz in previous
versions was broken, so you could not always do things like selecting the
columns for import and specifiying the data types to use for those columns
(even though the interface appeared to offer those choices.) That's fixed.
It's certainly improved, but I'm not sure how good it is in practice.

7. Compatibility Issues: is that an issue in converted MDBs as well
as in new ACCDBs?

The specified examples are a problem across the board in A2007.
The reinstallation coffee break applies regardless of file format.

8. Should I Buy section: I think that new users ought not buy it
unless they have no outside dependencies. That is, they aren't going
to share data with other users and don't have any existing
applications with a developer working on them. I just think an
unqualified "YES" is way too optimistic. Of course, I guess I'm
thinking more in terms of your second category. I still think the
first category oughn't be an unqualified affirmative, but a MAYBE. I
also just don't believe in the "learn it for the future" advice, as
that was the advice everyone gave for ADO when it was introduced in
Access. I didn't learn it, and, well, I have no regrets on that,
since Microsoft wised up and it's now deprecated in Access.

Yes, I'm thinking a "new user buying Office" (as distinct from "existing
Office user") is buying the whole suite for the first time, not just Access.
They have no previous experience, and need to learn their way around the
ribbon, not menus/toolbars. They will still be able to read, edit, and
create documents in the old formats (DOC, XLS, MDB, etc.)

Overall, from what you've written, it seems to me that A2K7 is a
disaster similar to A95 -- much worse than A2K.

Not sure you would say that if you had done some more extensive testing,
David. There's some seriously useful functionality here, and the future of
Access includes all this stuff. Because of many of the little things that
are just "there" and don't need to be programmed, developing in A2007 will
be faster than developing similar functionality in previous versions.

I worked with both the beta of Access 95 and Access 2007 for many months
before release, and 2007 does not have the stability problems (frequent
crashes) that 95 did. I had not worked on the beta of 2000, but actually
gave up on it after it was released. Certainly 2007 is not there yet, but at
least the starting line is within view.

[Allen Browne]

Valid points, Rick.

We probably should point out that you can use HTML for Memo fields only. You
cannot create a Text field and format it as HTML, and you cannot set a text
box to Rich Text if it is bound to a field of type Text. Also, the Search
box built into the interface handles formatted text properly IIRC.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Rick Brandt" <ri*********@hotmail.comwrote in message
news:%R****************@newssvr22.news.prodigy.net ...

David W. Fenton wrote:

>"Allen Browne" <Al*********@SeeSig.invalidwrote in
news:45***********************@per-qv1-newsreader-01.iinet.net.au:

>>If you are looking for opinon on what's useful in Access 2007,
there's a new article at:
http://allenbrowne.com/Access2007.html

Covers what's good (useful features), what's mixed (good and bad),
what's gone (features removed), what's fixed (old issues solved),
what's broken (new bugs), configuration, compatibility, should you
buy, and links.

It is opinion, so you may disagree, but hopefully it's an
informative summary.

Great article, Allen -- I really appreciate the work you've put into
preparing it.

Of coures, I have questions! :)

1. rich text: is the HTML *good* HTML, or the usual trashy, awful MS
stuff, with complex and idiosyncratic CSS? Is the HTML controllable?

I personally believe that this will be the cause of a huge number of
questions in these groups when used by people who don't understand what is
happening in the background. There are two major caveats to the Rich Text
(html) capability.

1) You are pretty much designating that no other application will interact
with the data in your field because no other app is going to be able to
properly display the text as stored.

2) From what I can tell you lose the ability in most cases to search the
data effectively. If you store "Some sample text" and make the word
"sample" display in red or bold or whatever then the following query will
not find it...

SELECT *
FROM TableName
WHERE FieldName = "Some sample text"

...because "Some sample text" is NOT what the table actually has stored in
it. It's going to be just like the lookup field problem. I would also
expect there will also be issues with trying to count characters, sorting
on the first 255 characters, parsing, etc..

I do think it's a nice feature, but as with many other things MS has done
to Access they are just foisting it on the unwashed masses who are not
going to understand all of the gotchas associated with it.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Lyle Fairfield]

Lyle Fairfield wrote:

Upon further review I see that ADPs can be created in Access 2007.

[Lyle Fairfield]

Lyle Fairfield wrote:

Lyle Fairfield wrote:

Upon further review I see that ADPs can be created in Access 2007.

It seems that ADPs take longer to load and that table browsing and such
archaic activities are slow.
But forms created in an Access 2007 ADP seem to me to be as fast as any
other forms with which I am familiar. And code runs just as quickly as
well.

So tonight I learned a couple of things that may encourage me to
continue with Access 2007.

I suggest to anyone who wants to know about Access 2007, that he or she
download the Trial Version (it runs for free for two months) and
explore and test it himself or herself. The Access world was much too
full of superstition prior to Access 2007. It doesn't need any more
fairy stories.

Lyle said, Allen said, David said ... they mean that Lyle said, Allen
said, David said ... they don't mean anything else.

No, I haven't learned how to do DAPs in Access 2007. But there seem to
be some promising possiblities in saving forms as XLT and/or somemember
of the XML family that will work with ASP. Who knows? Perhaps these are
superior to DAPs.

[Larry Linson]

"Lyle Fairfield" <ly***********@aim.comwrote

No, I haven't learned how to do DAPs in Access 2007. But there seem to
be some promising possiblities in saving forms as XLT and/or somemember
of the XML family that will work with ASP. Who knows? Perhaps these are
superior to DAPs.

Word was that you could run existing DAPs, but you'd have to keep the older
version installed to maintain them, or create new ones. I'm still waiting on
that new machine I ordered, to be able to load O2007 and experiment with it.

I've never done a DAP, but from some things you wrote, was wondering if DAPs
might be a way to create and distribute a simple application without
involving the runtime... then I read, 'way early in development of A2007,
that they were not only deprecating, but removing the capability to create,
DAPs. <SIGH>

Larry Linson
Microsoft Access MVP

[Rick Brandt]

"Allen Browne" <Al*********@SeeSig.invalidwrote in message
news:45***********************@per-qv1-newsreader-01.iinet.net.au...

Valid points, Rick.

We probably should point out that you can use HTML for Memo fields only. You
cannot create a Text field and format it as HTML, and you cannot set a text
box to Rich Text if it is bound to a field of type Text. Also, the Search box
built into the interface handles formatted text properly IIRC.

I wonder, does 2007 include a feature for extracting just the ASCII equivalent
from a Rich Text formatted field? I suppose one might be able to create a
function using Regular Expressions that would do it. I can see cases where
people might actually want a secondary (non-displayed) field that would hold the
"plain" entry. That could server as a work-around to some of the issues I
raised as would being able to examine that on the fly even if it were not
stored.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Allen Browne]

Can't see anything built in, Rick.

You are probably aware of MVP John Nurick's examples of regular expressions:
http://www.j.nurick.dial.pipex.com/C...rgxExtract.htm

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Rick Brandt" <ri*********@hotmail.comwrote in message
news:F6******************@newssvr14.news.prodigy.n et...

"Allen Browne" <Al*********@SeeSig.invalidwrote in message
news:45***********************@per-qv1-newsreader-01.iinet.net.au...

>Valid points, Rick.

We probably should point out that you can use HTML for Memo fields only.
You cannot create a Text field and format it as HTML, and you cannot set
a text box to Rich Text if it is bound to a field of type Text. Also, the
Search box built into the interface handles formatted text properly IIRC.

I wonder, does 2007 include a feature for extracting just the ASCII
equivalent from a Rich Text formatted field? I suppose one might be able
to create a function using Regular Expressions that would do it. I can
see cases where people might actually want a secondary (non-displayed)
field that would hold the "plain" entry. That could server as a
work-around to some of the issues I raised as would being able to examine
that on the fly even if it were not stored.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Stephen Lebans]

Hi Allen/Rick,
I do not have A2007 installed yet but I find it hard to believe that no
prop/method exists to access the plain text component. I think one of you
mentioned earlier that the formatted text is actaully stored as HTML. If so
then there are dozens of HTML to whatever conversion routines on the Web.
Hopefully there will be something in VB that can be ported easily to Access
VBA.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"Allen Browne" <Al*********@SeeSig.invalidwrote in message
news:45***********************@per-qv1-newsreader-01.iinet.net.au...

Can't see anything built in, Rick.

You are probably aware of MVP John Nurick's examples of regular
expressions:
http://www.j.nurick.dial.pipex.com/C...rgxExtract.htm

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Rick Brandt" <ri*********@hotmail.comwrote in message
news:F6******************@newssvr14.news.prodigy.n et...

>"Allen Browne" <Al*********@SeeSig.invalidwrote in message
news:45***********************@per-qv1-newsreader-01.iinet.net.au...

>>Valid points, Rick.

We probably should point out that you can use HTML for Memo fields only.
You cannot create a Text field and format it as HTML, and you cannot set
a text box to Rich Text if it is bound to a field of type Text. Also,
the Search box built into the interface handles formatted text properly
IIRC.

I wonder, does 2007 include a feature for extracting just the ASCII
equivalent from a Rich Text formatted field? I suppose one might be able
to create a function using Regular Expressions that would do it. I can
see cases where people might actually want a secondary (non-displayed)
field that would hold the "plain" entry. That could server as a
work-around to some of the issues I raised as would being able to examine
that on the fly even if it were not stored.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Darryl Kerkeslager]

Allen,

Thanks for the information on your web page. I have read several
articles on A2007, but none as helpful as yours. One of my biggest
complaints with Access has been the lack of options - Text(255) or Memo,
neither of which gave me satisfaction for the type of field that I want for
length, storage, formatting, and search. Apparently, I still can't always
get what I want.
--
Darryl Kerkeslager

[Darryl Kerkeslager]

"Lyle Fairfield" <ly***********@aim.comwrote

I suggest to anyone who wants to know about Access 2007, that he or she
download the Trial Version (it runs for free for two months) and
explore and test it himself or herself.

Will it play nicely with my existing Access 2003 installation, and will it
uninstall cleanly?
--
Darryl Kerkeslager

[Lyle Fairfield]

Darryl Kerkeslager wrote:

"Lyle Fairfield" <ly***********@aim.comwrote

I suggest to anyone who wants to know about Access 2007, that he or she
download the Trial Version (it runs for free for two months) and
explore and test it himself or herself.

Will it play nicely with my existing Access 2003 installation, and will it
uninstall cleanly?
--
Darryl Kerkeslager

Dream along!

[Lyle Fairfield]

Stephen Lebans wrote:

Hi Allen/Rick,
I do not have A2007 installed yet but I find it hard to believe that no
prop/method exists to access the plain text component. I think one of you
mentioned earlier that the formatted text is actaully stored as HTML. If so
then there are dozens of HTML to whatever conversion routines on the Web.
Hopefully there will be something in VB that can be ported easily to Access
VBA.

I suppose we could always try the new (in Access 2007) PlainText
function.

[Lyle Fairfield]

Lyle Fairfield wrote:

I suppose we could always try the new (in Access 2007) PlainText
function.

Function PlainText(RichText, [Length]) As String
Member of Access.Application

The old Object Browser still works.

[lyle fairfield]

Allen Browne wrote:

Thanks for your comments, David.
Responses embedded.

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...

"Allen Browne" <Al*********@SeeSig.invalidwrote in
news:45***********************@per-qv1-newsreader-01.iinet.net.au:

>If you are looking for opinon on what's useful in Access 2007,
there's a new article at:
http://allenbrowne.com/Access2007.html

Covers what's good (useful features), what's mixed (good and bad),
what's gone (features removed), what's fixed (old issues solved),
what's broken (new bugs), configuration, compatibility, should you
buy, and links.

It is opinion, so you may disagree, but hopefully it's an
informative summary.

Great article, Allen -- I really appreciate the work you've put into
preparing it.

Of coures, I have questions! :)

1. rich text: is the HTML *good* HTML, or the usual trashy, awful MS
stuff, with complex and idiosyncratic CSS? Is the HTML controllable?

It's quite basic HTML, used to format the text, not a full HTML page.
Therefore there is no header, no CSS. Use Div for paragraphs. Not
particularly nice, but it works.

*_
This Response created in Access 2007 Rich text Box_*.

1. seems
2. to
3. have
4. same
5. /capabilities/
6. as
7. word
8. from the *popup* menu
9. that is

oh dear, am I posting in HTML? ... I'm so ashamed!

[David W. Fenton]

"Allen Browne" <Al*********@SeeSig.invalidwrote in
news:45***********************@per-qv1-newsreader-01.iinet.net.au:

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...

[]

>Overall, from what you've written, it seems to me that A2K7 is a
disaster similar to A95 -- much worse than A2K.

Not sure you would say that if you had done some more extensive
testing, David. There's some seriously useful functionality here,
and the future of Access includes all this stuff.

But A95 was a similarly huge release, with the introduction of VBA
and all that entailed. The potential for that was HUGE, and the
whole future of Access was completely changed by it.

Because of many of the little things that
are just "there" and don't need to be programmed, developing in
A2007 will be faster than developing similar functionality in
previous versions.

The improvements to the report designer alone sound like enormous
productivity improvements.

I worked with both the beta of Access 95 and Access 2007 for many
months before release, and 2007 does not have the stability
problems (frequent crashes) that 95 did. I had not worked on the
beta of 2000, but actually gave up on it after it was released.
Certainly 2007 is not there yet, but at least the starting line is
within view.

Well, the difference may be that most of the real problems with A2K7
are BY DESIGN, whereas most of the problems with A95 were just plain
old bugs. Maybe it *is* closer to A2K, where about half the major
problems were BY DESIGN and half were bugs.

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

[Allen Browne]

Yes: PlainText() works fine.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Lyle Fairfield" <ly***********@aim.comwrote in message
news:11*********************@73g2000cwn.googlegrou ps.com...

Lyle Fairfield wrote:

>I suppose we could always try the new (in Access 2007) PlainText
function.

Function PlainText(RichText, [Length]) As String
Member of Access.Application

The old Object Browser still works.

[Allen Browne]

What did you want, Darryl?

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Darryl Kerkeslager" <ke*********@comcast.netwrote in message
news:4u******************************@comcast.com. ..

>
Thanks for the information on your web page. I have read several
articles on A2007, but none as helpful as yours. One of my biggest
complaints with Access has been the lack of options - Text(255) or Memo,
neither of which gave me satisfaction for the type of field that I want
for length, storage, formatting, and search. Apparently, I still can't
always get what I want.
--
Darryl Kerkeslager

[Larry Linson]

"Lyle Fairfield" wrote

I suppose we could always try the new
(in Access 2007) PlainText function.

Killjoy!

[Darryl Kerkeslager]

What did you want, Darryl?

1. A text field of up to 4000 characters instead of a pathetic 255.

2. An rtf field that is searchable, formattable, and doesn't bloat the db.

3. A Nintendo Wii

--
Darryl Kerkeslager

"Allen Browne" <Al*********@SeeSig.invalidwrote

>

"Darryl Kerkeslager" wrote

> Thanks for the information on your web page. I have read several
articles on A2007, but none as helpful as yours. One of my biggest
complaints with Access has been the lack of options - Text(255) or Memo,
neither of which gave me satisfaction for the type of field that I want
for length, storage, formatting, and search. Apparently, I still can't
always get what I want.

[Larry Linson]

"Darryl Kerkeslager" <ke*********@comcast.netwrote

1. A text field of up to 4000 characters
instead of a pathetic 255.

As text and memo fields are both stored "variable length", it doesn't cost
any storage to store the 4000-character data in a Memo. You do lose some
searching ability in Querys on the Memo. I'd be happier to get "full search
capability" on Memo type data.

2. An rtf field that is searchable, formattable,
and doesn't bloat the db.

I may be mistaken, but believe Access 2007 has eliminated (or at least,
minimized) the bloating problem for information stored as OLE Objects.

3. A Nintendo Wii

Sorry about that. You'll have to find a retailer who puts together some
unusual "package deals" to get that one.

Larry Linson
Microsoft Access MVP

[John Vinson]

On Sun, 24 Dec 2006 20:06:32 GMT, "Larry Linson"
<bo*****@localhost.notwrote:

>"Darryl Kerkeslager" <ke*********@comcast.netwrote

1. A text field of up to 4000 characters
instead of a pathetic 255.

As text and memo fields are both stored "variable length", it doesn't cost
any storage to store the 4000-character data in a Memo. You do lose some
searching ability in Querys on the Memo. I'd be happier to get "full search
capability" on Memo type data.

Well... memos are fully searchable using equal or LIKE searching. What
you lose is the indexing, of course, so the searching is slower.

2. An rtf field that is searchable, formattable,
and doesn't bloat the db.

I may be mistaken, but believe Access 2007 has eliminated (or at least,
minimized) the bloating problem for information stored as OLE Objects.

That's my understanding too.

3. A Nintendo Wii

<gand a pony and a Lionel train set...

John W. Vinson[MVP]

[David W. Fenton]

"Larry Linson" <bo*****@localhost.notwrote in
news:c5Bjh.1230$4e.145@trnddc04:

"Darryl Kerkeslager" <ke*********@comcast.netwrote

1. A text field of up to 4000 characters
instead of a pathetic 255.

As text and memo fields are both stored "variable length", it
doesn't cost any storage to store the 4000-character data in a
Memo.

Yes, but memo fields are dangerous because the pointer is so easily
corrupted. Of course, a Char(4K) field would be a problem, as it
really couldn't be stored inline in the data page, either, as it
would be too long for the maximum record length.

You do lose some
searching ability in Querys on the Memo. I'd be happier to get
"full search capability" on Memo type data.

2. An rtf field that is searchable, formattable,
and doesn't bloat the db.

I may be mistaken, but believe Access 2007 has eliminated (or at
least, minimized) the bloating problem for information stored as
OLE Objects.

It would be interesting to see a direct comparison between an MDB
OLE field with an ACCDB OLE field with the same object stored in it.

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

[Darryl Kerkeslager]

"David W. Fenton" <XX*******@dfenton.com.invalidwrote

Of course, a Char(4K) field would be a problem, as it
really couldn't be stored inline in the data page, either, as it
would be too long for the maximum record length.

Does that mean it will never happen? Perhaps 4k was too much to ask for,
but certainly more than 255?

I have used memo fields sparingly on reasonable-sounding advice, but the
text(255) fields are just too small.
--
Darryl Kerkeslager

[John Vinson]

On Sun, 24 Dec 2006 19:59:41 -0500, "Darryl Kerkeslager"
<ke*********@comcast.netwrote:

>I have used memo fields sparingly on reasonable-sounding advice, but the
text(255) fields are just too small.

I have had just a couple of instances of memo-related corruption. I'd
(based on inadequate testing or evidence) be cautious about having
memo fields which are constantly being edited; but for free-format
readable text that's stored and displayed with a record, I don't see
why one shouldn't use memo fields. They *do* work.

John W. Vinson[MVP]

[David W. Fenton]

John Vinson <jvinson@STOP_SPAM.WysardOfInfo.comwrote in
news:hu********************************@4ax.com:

On Sun, 24 Dec 2006 19:59:41 -0500, "Darryl Kerkeslager"
<ke*********@comcast.netwrote:

>>I have used memo fields sparingly on reasonable-sounding advice,
but the text(255) fields are just too small.

I have had just a couple of instances of memo-related corruption.
I'd (based on inadequate testing or evidence) be cautious about
having memo fields which are constantly being edited; but for
free-format readable text that's stored and displayed with a
record, I don't see why one shouldn't use memo fields. They *do*
work.

You can ameliorate the danger by editing them unbound. You don't
have to update them with DAO, you just include them in your form's
recordsource and don't bind them to a control. Use the OnCurrent to
populate the textbox for the memo and the memo's AfterUpdate to save
the changes to the underlying field.

Also, you can make it a lot safer by putting your memo fields in a
separate 1:1 table, so that if the memo pointer gets corrupted,
you'll lose a record in that table, but not in your main table.

Between them, these approaches make memo fields pretty darned safe,
seems to me.

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

[John Vinson]

On Sun, 24 Dec 2006 20:27:44 -0600, "David W. Fenton"
<XX*******@dfenton.com.invalidwrote:

>You can ameliorate the danger by editing them unbound. You don't
have to update them with DAO, you just include them in your form's
recordsource and don't bind them to a control. Use the OnCurrent to
populate the textbox for the memo and the memo's AfterUpdate to save
the changes to the underlying field.

Also, you can make it a lot safer by putting your memo fields in a
separate 1:1 table, so that if the memo pointer gets corrupted,
you'll lose a record in that table, but not in your main table.

I've read (and used, once) the latter trick, but the first one is new
to me. Thanks David!

John W. Vinson[MVP]

[Rick Brandt]

Darryl Kerkeslager wrote:

"David W. Fenton" <XX*******@dfenton.com.invalidwrote

Of course, a Char(4K) field would be a problem, as it
really couldn't be stored inline in the data page, either, as it
would be too long for the maximum record length.

Does that mean it will never happen? Perhaps 4k was too much to ask
for, but certainly more than 255?

I have used memo fields sparingly on reasonable-sounding advice, but
the text(255) fields are just too small.

I suspect that the reason that they don't provide larger text sizes is because
the increase in file size should a user index them might not be practical
whereas the server databases don't have that issue. I believe our IBM box allows
VarChar all the way up to 32000 now which seems a bit extreme to me.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Darryl Kerkeslager]

Thanks, David. I don't think I had seen that put that way before.

--
Darryl Kerkeslager

"David W. Fenton" <XX*******@dfenton.com.invalidwrote

You can ameliorate the danger by editing them unbound. You don't
have to update them with DAO, you just include them in your form's
recordsource and don't bind them to a control. Use the OnCurrent to
populate the textbox for the memo and the memo's AfterUpdate to save
the changes to the underlying field.

Also, you can make it a lot safer by putting your memo fields in a
separate 1:1 table, so that if the memo pointer gets corrupted,
you'll lose a record in that table, but not in your main table.

[f_l_louw]

Hi Allen,

We have an A2000 ADP app that runs in our branch offices in 100+
countries. A2000 was a great technology for us, but it is time to move
on. I was really looking forward to A2007, and was glad to see that
ADP continues to be supported.

Then the bad news. The first time I opened a form bound to a simple
stored proc like:

CREATE PROCEDURE dbo.spselTableName
AS
SET NOCOUNT ON
SELECT * FROM dbo.TableName

Where TableName is a simple reference table with less than 10 fields
and a dozen records, It took more than a minute to open! I put a trace
on to see what was happening, and I noticed loads of code like this:

select object_name(sotblfk.id), user_name(sotblfk.uid),
object_name(sotblrk.id), user_name(sotblrk.uid) from sysreferences
srfk,
sysobjects sofk, sysobjects sotblfk, sysobjects sotblrk where
srfk.constid =
sofk.id and srfk.fkeyid = sotblfk.id and srfk.rkeyid = sotblrk.id and
user_name(sofk.uid) = N'dbo' and object_name(sofk.id) =
N'FK_ForeignKeyTableName_TableName_PrimaryKeyField Name'

It looks like A2007 is interpreting the foreign key relationships in
the SQL database. In our SQL 2000 database (1400 tables, about 3000
relationships) each of these calls generates about 100,000 reads. That
is really, really nasty. It is even worse in SQL 2005. A2000 never
did this, so the same form is lightning fast in A2000, but dead slow in
A2007.

What happened?? IMHO, this problem kills ADP as a usable technology
for corporate development. The most attractive upgrade path for us
would have been A2007, but now we are looking at a complete re-write of
our app. Not so nice.

Any suggestions?

Thanks,
Francois Louw

[Allen Browne]

Perhaps someone who uses ADPs can comment on this.
Thanks for posting.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

<f_******@yahoo.co.ukwrote in message
news:11**********************@f1g2000cwa.googlegro ups.com...

Hi Allen,

We have an A2000 ADP app that runs in our branch offices in 100+
countries. A2000 was a great technology for us, but it is time to move
on. I was really looking forward to A2007, and was glad to see that
ADP continues to be supported.

Then the bad news. The first time I opened a form bound to a simple
stored proc like:

CREATE PROCEDURE dbo.spselTableName
AS
SET NOCOUNT ON
SELECT * FROM dbo.TableName

Where TableName is a simple reference table with less than 10 fields
and a dozen records, It took more than a minute to open! I put a trace
on to see what was happening, and I noticed loads of code like this:

select object_name(sotblfk.id), user_name(sotblfk.uid),
object_name(sotblrk.id), user_name(sotblrk.uid) from sysreferences
srfk,
sysobjects sofk, sysobjects sotblfk, sysobjects sotblrk where
srfk.constid =
sofk.id and srfk.fkeyid = sotblfk.id and srfk.rkeyid = sotblrk.id and
user_name(sofk.uid) = N'dbo' and object_name(sofk.id) =
N'FK_ForeignKeyTableName_TableName_PrimaryKeyField Name'

It looks like A2007 is interpreting the foreign key relationships in
the SQL database. In our SQL 2000 database (1400 tables, about 3000
relationships) each of these calls generates about 100,000 reads. That
is really, really nasty. It is even worse in SQL 2005. A2000 never
did this, so the same form is lightning fast in A2000, but dead slow in
A2007.

What happened?? IMHO, this problem kills ADP as a usable technology
for corporate development. The most attractive upgrade path for us
would have been A2007, but now we are looking at a complete re-write of
our app. Not so nice.

Any suggestions?

Thanks,
Francois Louw

[Lyle Fairfield]

f_******@yahoo.co.uk wrote:

Hi Allen,

We have an A2000 ADP app that runs in our branch offices in 100+
countries. A2000 was a great technology for us, but it is time to move
on. I was really looking forward to A2007, and was glad to see that
ADP continues to be supported.

Then the bad news. The first time I opened a form bound to a simple
stored proc like:

CREATE PROCEDURE dbo.spselTableName
AS
SET NOCOUNT ON
SELECT * FROM dbo.TableName

Where TableName is a simple reference table with less than 10 fields
and a dozen records, It took more than a minute to open! I put a trace
on to see what was happening, and I noticed loads of code like this:

select object_name(sotblfk.id), user_name(sotblfk.uid),
object_name(sotblrk.id), user_name(sotblrk.uid) from sysreferences
srfk,
sysobjects sofk, sysobjects sotblfk, sysobjects sotblrk where
srfk.constid =
sofk.id and srfk.fkeyid = sotblfk.id and srfk.rkeyid = sotblrk.id and
user_name(sofk.uid) = N'dbo' and object_name(sofk.id) =
N'FK_ForeignKeyTableName_TableName_PrimaryKeyField Name'

It looks like A2007 is interpreting the foreign key relationships in
the SQL database. In our SQL 2000 database (1400 tables, about 3000
relationships) each of these calls generates about 100,000 reads. That
is really, really nasty. It is even worse in SQL 2005. A2000 never
did this, so the same form is lightning fast in A2000, but dead slow in
A2007.

What happened?? IMHO, this problem kills ADP as a usable technology
for corporate development. The most attractive upgrade path for us
would have been A2007, but now we are looking at a complete re-write of
our app. Not so nice.

Any suggestions?

Thanks,
Francois Louw

Perhaps we should all read and explore a bit more and report our
findings.

I too have found my ADPs so slow as to be useless in Access 2007.

I haven't tested this solution enough to venture an opinion as to why
or how, but I have found that a newly created (in 2007) ADP operates
just as quickly in 2007 as other ADPs do in 2003. When I import forms
and reports from the old 2003 created ADP to the new 2007 created ADP
they work just as quickly as before.

This has worked for two ADPs here, one connected to a local SQLExpress
Server, and one connected to a remote SQL-2000 server.

[ManningFan]

Or you can get the full version of Office 2007 for free from your
favorite torrent site. ;o)

Lyle Fairfield wrote:

I suggest to anyone who wants to know about Access 2007, that he or she
download the Trial Version (it runs for free for two months) and
explore and test it himself or herself.

[Rich P]

I have used ADP's extensively over the last 3 or 4 years, but not in
Acc2007. ADP's are OK front end to sql server, but between performance
and write conflicts (the most prominent issues I have encountered) and a
few other issues -- for every 1000 lines of code I have written in an
ADP - I can write the same code in 50 - 100 lines in .Net. Where I
really suck up the lines of code in an ADP is when I have to do system
level stuff which requires several lines of API code. The same thing
can usually be accomplished in one line in .Net. The biggest drawback
of the ADP is if you do a lot of I/O stuff. With the .Net disconnected
recordsets - there is virtually no I/O.

For straight forward mdb operations - it sounds like Acc2007 may be a
better performer than its predecessors. But in the corporate
environment - using sql server as the backend - I don't think Acc2007
will deliver any more than its predecessors. I think Access will see
the most improvement when it becomes .Net compliant (when it becomes
object oriented and managed code).

Rich

*** Sent via Developersdex http://www.developersdex.com ***

[aaron.kempf]

yeah how fucking DARE you spread misinformation on ADP?

we should have _HELPED_ the JAPS invade your wimpy-ass 'country' in WW2
-Aaron


Allen Browne wrote:

If you are looking for opinon on what's useful in Access 2007, there's a new
article at:
http://allenbrowne.com/Access2007.html

Covers what's good (useful features), what's mixed (good and bad), what's
gone (features removed), what's fixed (old issues solved), what's broken
(new bugs), configuration, compatibility, should you buy, and links.

It is opinion, so you may disagree, but hopefully it's an informative
summary.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

[Larry Linson]

<aa*********@gmail.comwrote

yeah how fucking DARE you spread mis-
information on ADP?

Among the rankings of those who have "spread misinformation" here, you are
"right up there," aaron. If anyone took your ranting seriously, you'd easily
fall in the category of "disruptive poster." (Another name for "disruptive
poster" would be "troll".)

we should have _HELPED_ the JAPS
invade your wimpy-ass 'country' in WW2

Keep trying, as there are probably other nationalities you haven't publicly
insulted yet -- but with your vast talent in the area of insult, I'm sure
you'll get around to covering them all.

Larry

[Francois Louw]

I checked out your suggestion, and creating a new ADP in 2007 and
importing all objects rather than opening one created in 2003 or 2000
definitely improves performance. However, the trace still reveals the
selects against sysobjects. One commonly used reference table in one
of our databases has 38 FK relationships. Each one generates a select
against sysobjects, 98,000 reads each time. That makes 3,724,000 reads
just to open the form.

Ok, the form is not opened very much, being reference data that isn't
acessed very often, but 3.7 million reads is still nasty.

Lyle Fairfield wrote:

Perhaps we should all read and explore a bit more and report our
findings.

I too have found my ADPs so slow as to be useless in Access 2007.

I haven't tested this solution enough to venture an opinion as to why
or how, but I have found that a newly created (in 2007) ADP operates
just as quickly in 2007 as other ADPs do in 2003. When I import forms
and reports from the old 2003 created ADP to the new 2007 created ADP
they work just as quickly as before.

This has worked for two ADPs here, one connected to a local SQLExpress
Server, and one connected to a remote SQL-2000 server.

[Francois Louw]

asinine and ignorant. what a delightful combination.

aa*********@gmail.com wrote:

yeah how fucking DARE you spread misinformation on ADP?

we should have _HELPED_ the JAPS invade your wimpy-ass 'country' in WW2
-Aaron

[Lyle Fairfield]

"Francois Louw" <f_******@yahoo.co.ukwrote in
news:11**********************@s34g2000cwa.googlegr oups.com:

I checked out your suggestion, and creating a new ADP in 2007 and
importing all objects rather than opening one created in 2003 or 2000
definitely improves performance. However, the trace still reveals the
selects against sysobjects. One commonly used reference table in one
of our databases has 38 FK relationships. Each one generates a select
against sysobjects, 98,000 reads each time. That makes 3,724,000 reads
just to open the form.

Ok, the form is not opened very much, being reference data that isn't
accessed very often, but 3.7 million reads is still nasty.

I tried responding on Google a few minutes ago but the posting seemed to
fail. I apologize if this is a duplicate (and even more if it appears to be
but is not.)
I know very little of tracing.
There seems to be no easily available utility accompanying SQLExpress
(2005) for reading trace files.
SQLExpress maintains a default trace unless it is turned off.
I wrote a couple of Sprocs, one to read the location of the default trace
file and another to return its contents in table form.
I fooled with the ADP for two hours with that task and opening various
forms and views as a means of testing.
My trace table has 466 rows. The time-date information covers the time I
was working with the ADP. It seems to have a row for each action I took.
There was no evidence of scanning the SysObjects table.

Perhaps we are not talking about the same thing?

Perhaps we did not create our new ADP (in Access 2007) in the same way. I'm
embarrassed to tell how I do it, as it seems "Hackish". Perhaps you have
discovered the easy, approved way and will tell us?

--
lyle fairfield

[Lyle Fairfield]

aa*********@gmail.com wrote:

yeah how fucking DARE you spread misinformation on ADP?

we should have _HELPED_ the JAPS invade your wimpy-ass 'country' in WW2

Why spoil your helpful contributions with this nonsense, Aaron? You
have plenty of knowledge; you can be very helpful; why cover this with
the darkness of anger?

Yes, I know; for a long time you pointed out the strengths of ADPs and
the errors of those who denigrated them. You were ignored or derided.
Your statements were twisted.

After years of that many would feel like lashing out.

But is that effective? Does it work? Does it result in a greater or
lesser likelihood that your position will be considerd?

I think ADPs are fabulous. Once you get into them, you forget MDBs. But
I've rejected them because of my failure to find any sound way of
controlling, beyond the scope of the ADP, the permssions which their
users must have. Recently I've come to believe, (but I'm not 100% sure)
that MS-SQL/ODBC connected Access mdbs have the same potential for
misuse of permissions. If that's true then I'm back on the ADP
bandwagon.

[Tim Marshall]

aa*********@gmail.com wrote:

yeah how fucking DARE you spread misinformation on ADP?

we should have _HELPED_ the JAPS invade your wimpy-ass 'country' in WW2

I didn't see any smileys.... so...

You are an ignoramus of the highest degree. The Aussies were dying
fighting "the JAPS" (as you call them) up to a year after the Americans
declared victory in 1945. Of course, you knew that. Boy, if the whole
world was as knowledgeable as you are, what a place it would be... You
must be an advisor to the current American president.

Regardless of where Allen is posting from, to attack someone who has
given so much to the Access development community requires a public apology.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Francois Louw]

My database is in SQL 2000, and I used the SQL 2000 Profiler utility,
checking for TSQL events of type SQL:StmtCompleted, with a filter for
my mahine name as HostName. After starting the trace, I then just open
the form, and sit back to watch the fireworks. The profiler shows the
TSQL commands executed by Access, along with the number of database
reads generated by each one, and some other statistcal information.

I use Profiler extensively to see what IO Access is generating on the
SQL server. Access 2000 ASPs are remarkably well behaved, and generate
very clean, pretty efficient TSQL code. I just wish Access 2007 would
do the same.

Btw, SQL 2005 has the same utility in the managment studio. I'm not
sure about the express version though.

The way I created my ADP in Access 2007 is: Office Button. New. Browse
for the location of the database (hit the folder icon). Change the
"Save as type" to ADP.

Thanks,
Francois Louw

Lyle Fairfield wrote:

I tried responding on Google a few minutes ago but the posting seemed to
fail. I apologize if this is a duplicate (and even more if it appears to be
but is not.)
I know very little of tracing.
There seems to be no easily available utility accompanying SQLExpress
(2005) for reading trace files.
SQLExpress maintains a default trace unless it is turned off.
I wrote a couple of Sprocs, one to read the location of the default trace
file and another to return its contents in table form.
I fooled with the ADP for two hours with that task and opening various
forms and views as a means of testing.
My trace table has 466 rows. The time-date information covers the time I
was working with the ADP. It seems to have a row for each action I took.
There was no evidence of scanning the SysObjects table.

Perhaps we are not talking about the same thing?

Perhaps we did not create our new ADP (in Access 2007) in the same way. I'm
embarrassed to tell how I do it, as it seems "Hackish". Perhaps you have
discovered the easy, approved way and will tell us?

--
lyle fairfield