Opinion on Access 2007

[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.

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/Code/vbRegex/rgxExtract.htm

 

[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]

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?

 

[Lyle Fairfield]

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

Dream along!

 

[Lyle Fairfield]

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]

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]

Thanks for your comments, David.
Responses embedded.

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]

[]

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.

 

[Allen Browne]

Yes: PlainText() works fine.

--
Allen Browne - Microsoft MVP. Perth, Western Australia

Reply to group, rather than allenbrowne at mvps dot org.

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?

 

[Larry Linson]

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

 

[Larry Linson]

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]

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.

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.

<g> and a pony and a Lionel train set...

John W. Vinson[MVP]

 

[David W. Fenton]

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.


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.

 

[Darryl Kerkeslager]

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.

 

[John Vinson]

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]

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.

 

[John Vinson]

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]

 

[David F Cox]

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

The "Import from SantaLand" option is long overdue -<)