469,292 Members | 1,326 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,292 developers. It's quick & easy.

Are there known issues with Vista and Acc2003

I have a rather complex commercial Acc2003 application (tab controls,
50K+ lines of VBA code, etc.) that will not run well at all on Windows
Vista Ultimate. I have seen posts indicating that Acc2003 MDBs should
work on Vista. However, our particular file has too many problems to
be viable on a Vista platform. Even converting it to an Acc2007 accdb
file has no positive effect.

I realize that Vista is new and should be avoided like the plague, but
we have few choices if some of our clients go to Vista.

We have been all over the MS knowledgebase and these groups without
much luck. Are there any lists of known issues and or suggestions
gathered during Vista beta that are available and if so, where?

Any and all help is greatly appreciated….

Feb 26 '07
62 4621
On Feb 28, 7:31 pm, "Lyle Fairfield" <lylefairfi...@aim.comwrote:
Micorsoft to take down this page
where it says:

ADO will continue to be ENHANCED
Jet is DEPRECATED
and
DAO is OBSOLETE,

http://msdn2.microsoft.com/en-us/library/ms810810.aspx

entitled Data Access Technologies Road Map
My view is that the article relates to Jet-no-Access and pre-dates
Access+ACE. Jet as a Windows component may be deprecated but the
Access team have a private branch of the code which they've 're-
branded' as ACE. DAO *has* been enhanced as ACEDAO.DLL (and don't
expect MSFT to admit they were wrong/mislead us about DAO <g>).

Jamie.

--
Mar 1 '07 #51
On Feb 28, 5:06 pm, "Baz" <b...@REMOVEbcap.THEeuro1net.CAPScomwrote:
According to that quote of which you were so proud, this ADO
6.0 is "functionally identical" to the previous version, which suggests to
me that it's only purpose is to provide backward compatibility. Presumably
there were technical reasons why the previous version wouldn't work under
Vista (or, it is in fact exactly the same thing and they just renamed it).

I fail to understand why you are so keen to prove that ADO has a future.
I'm not trying to prove "ADO has a future". I'm just trying to
reconcile your points "ADO is DEAD" with "MSFT have made it backward
compatible for Vista" and I have been unable to :(

Jamie.

--
Mar 1 '07 #52
On Feb 28, 5:08 pm, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
table-level CHECK
constraints

The Jet db engine doesn't support the features you are talking
about.
You are mistaken. See:

How to Create a Jet CHECK Constraint
http://support.microsoft.com/kb/201888
"The new SQL grammar exposed by Microsoft Jet database engine version
4.0 allows users to specify business rules that can span more than one
table. These are called check constraints and allow users to exceed a
single validation rule per table..."

Description of the new features that are included in Microsoft Jet 4.0
http://support.microsoft.com/kb/275561
"One new feature added to the Jet CREATE TABLE syntax is Check
Constraints. This new SQL grammar allows the user to specify business
rules that can span more than one table..."

Intermediate Microsoft Jet SQL for Access 2000
http://msdn2.microsoft.com/en-us/lib...ffice.10).aspx
"A check constraint is a powerful new [Jet] SQL feature that allows
you to add data validation to a table by creating an expression that
can refer to a single field, or multiple fields across one or more
tables."
And they aren't really relevant to a data interface language
like ADO, anyway. Setting them up and modifying them is a matter of
DDL for the relevant database engine, and I doubt that Jet or ADO
mucks around with DDL statements before handing them off to a
server.
Well, in this case the 'server' is Jet/ACE and the DDL is Jet SQL so
Jet/ACE indeed "mucks around" with the DDL. ADO is relevant here
because you must use ANSI-92 Query Mode to execute the DDL and to do
this in code you need to use the OLE DB Provider (for Jet 4.0 or ACE)
for which you need to use ADODB or ADOX. DAO/DAOACE has yet to be
enhanced to support the required DDL.
Microsoft purposely muddied the waters by intentionally not updating
DAO 3.6 to support new features in Jet 4, and added support for a
handful of Jet features only in ADO.
Agreed.
I hope that with A2K7 and a new
commitment to DAO and Jet, that MS has done the right thing and
implemented direct support for all of the features of the db engine.
I hope so too but they haven't achieved it in time for A2K7 :(

Jamie.

--
Mar 1 '07 #53
"onedaywhen" <ja**********@xsmail.comwrote
From the 'outside' it's hard to see how things will
play out e.g. DAO has made a comeback seemingly
against MSFT's game plan so will ADP survive in
coming years with enough support to make it viable?
My observations elsewhere for many years, and of Microsoft in recent years,
make me certain that predicting anything more than one version ahead is just
a wild guess (and, that is sometimes true even for 'the next version'). For
example, I sincerely doubt that, two versions back, anyone outside
Microsoft, including FrontPage MVPs, would have predicted FrontPage would be
gone by now (although it has two "offspring" that will carry on the
tradition -- SharePoint Designer and Web Expressions) but there is not, and
will not be, a FrontPage 2007.

My impression is that Microsoft's emphasis for Access, now, is as an
end-user tool for the Information Worker and that ADP was a "developer"
emphasis, so I would be concerned -- but that's not based on anything but
the aforementioned "wild guesses". In the MDB world, I note that the Control
Wizards no longer generate VBA in Access 2007, but generate (the improved?)
macros, instead, and that, I take as some confirmation of my view of their
revised emphasis.

I do, indeed, believe that classic ADO has been superceded in the Microsoft
development world. The "poor old fellow" has been taken in to the Access
assisted-living facility and is being nursed along with occasional doses of
Software Growth Hormone (e.g., the support for ACCDB); the "young and
vigorous" ADO.NET is thriving in the Microsoft "world of development" which
is, patently obvious to the casual observer, DotNet-centric, not
Office-centric.

Larry Linson
Microsoft Access MVP
(and Independent Prognosticator with Extremely Cloudy Crystal Ball)
Mar 1 '07 #54
"Lyle Fairfield" <ly***********@aim.comwrote in
news:11**********************@j27g2000cwj.googlegr oups.com:
On Feb 27, 6:20 pm, "David W. Fenton"
<XXXuse...@dfenton.com.invalidwrote:
>"onedaywhen" <jamiecoll...@xsmail.comwrote
innews:11*********************@k78g2000cwa.google groups.com:
What about, for example, back in 2000 when the "Access
development and support team at Microsoft" were saying things
such as, "In previous versions of Access, Data Access Objects
(DAO) was the primary data access method. That has now changed.
Although DAO is still supported, the new way to access data is
with ADO." (http://msdn2.microsoft.com/
en-us/library/aa140015(office.10).aspx)? My impression is that
you took the "no longer recommended" path and stuck with DAO,
even for new projects. Isn't it reasonable for someone to take
the same approach now with ADP, ADO, etc?

No, it is not.

HTH.

(think about the difference between a native technology and a
translation layer)

David has used ADO not at all, or very little.
I tried it out. I've worked with ADO code in existing apps. I've
read tons of documentation with ADO code (and it's ugly
stepchildren, like JRO). I've been doing all of these things since
1999.
He has not studied it.
I studied it extensively in the early days, when I first got the ADH
for Access 2000. Given my client base, it was of no use to me. Had I
apps with SQL Server back ends, I would likely have used ADO for
certain operations in that context.
He has neither the skills nor the experience to implement it, yet
he constantly denigrates it and expresses absolute opinions about
it.
You don't have to be an architect to tell that a house is falling
down.
David is not alone. He is joined by MVPs and other experienced
Access developers. I often wonder why. Is it because they are
inherently conservative and do not trust this new (what 1998?)
technology?
It was obvious that the ADO-everywhere push by Microsoft with the
release of A2K was a mistake for Jet projects. It was obvious to me
that the whole basis of ADPs (i.e., a Jet-less front end to server
data) was based on an unjust prejudice against Jet, caused by
ignorance and misunderstanding of Jet by developers who never
bothered to learn how to use it properly.

The problems with ADPs emerged quickly. Developers like Steve
Jorgensen tried very hard to make ADPs work and he was no slouch in
the programming department -- a very smart guy. If he couldn't make
it work, then nobody could. And he gave up on ADPs completely after
the second version fixed some bugs while adding new ones.
Is it
because they have a cozy business based upon Access and DAO?
I never criticized ADO in a non-Jet context. Ever. I only criticized
the ADO-with-Jet approache, which was always completely nonsensical.
I also criticized (as above) the philosophical foundation for the
introduction of the ADP (i.e., "avoid Jet at all costs"). As it
turns out, Microsoft has now adopted the very same position I was
advocating back in 1999-2000 with regard to ADO and ADPs.
Is it
because they do not have the intellectual capacity to keep several
technologies active in their brains at the same time? I don't
know.
I used the technologies that were appropriate for my clients, none
of whom use SQL Server. I learned to work with SQL Server because I
saw the need for upsizing with some of my clients. But here almost 8
years later, none of my clients have upsized (even though I've
suggested that it would be a good idea to consider it very
seriously) because Jet has worked so well with the apps I've written
for them that they just can't justify the conversion and admin
expenses.

It didn't take a genius to understand that the recommendation by MS
to use ADO with Jet data was a mistake. It didn't take a polymath to
see that the basic idea behind ADPs was problematic.
I
don't care. I can and have used DAO and ADO extensively. I have
forgotten more about DAO than many of its champions know; I have
used ADO more extensively than most. Each is a fine technology.
And I've never said ADO was a bad technology *in the proper
context*. Jet is *not* the proper context for it.
I like ADO;
it has a broad list of capabilities and it has a broad list of
situations in which it can be used.
As a successor to ODBC it's quite good.
The notion that it is dead is
absurd.
It is dead, Lyle. MS has moved on to ADO.NET and ADO is not being
developed any more.

DAO *was* dead in 1999, but it's alive again with the release of
A2K7 because MS wised up. It's not going to be "classic DAO,"
though, but a new version that will likely be updated for
compatibility with the new data format.
But when it's advantageous to use DAO, I use DAO.
But Lyle, that's precisely the argument I made for DAO from the very
beginning. I have always said that DAO was appropriate for Jet data,
though ADO was useful with Jet for a handful of features that DAO
didn't offer.

That has been my position from the beginning.

I *never* criticized the use of ADO in ADPs or with SQL Server data.

But once MS moved on to ADO.NET, classic ADO was clearly a legacy
technology, and the whole "learn it because it's the future"
justification for utilizing it in Jet-based apps went away entirely
(it was always a very weak argument).
What I do
care about and think that this newsgroup avoids is not the future
of ADO, nor of DAO. It is the future of Microsoft. Ten years ago
Microsoft did everything better; it was vibrant and it was
developing technologies which were needed and wanted. Today it is
developing redundant technologies to hawk.
I would agree with this. Office 97 was an amazing platform. But with
A2K, MS abandoned many of the promises of A97 because it wanted to
extend itself into the Enterprise market. And the design of A2K was
driven by that agenda, instead of what was best for the existing
base of Access developers and users.

Michael Kaplan published that article showing how the emperor had no
clothes and he took lots of heat from MS for it. But history has
borne out his judgments pretty darned well.

And that was the point at which I lost faith in Microsoft, because
it was clear that their priorities no longer matched those of my
client base.
I have learned all about .Net except
for one tiny thing: where I would want to use it.
I think it's obvious where .NET is a good platform -- for complex
browser-based apps. The whole CLR is a bust, though, in my opinion.
I don't see people using it to write cross-platform apps at all.
Oh I know, it's
Superior! And it may be for some. But I have not found that it is
superior for an experienced programmer/developer. And no, I don't
like apps which can do in ten thousand lines what I used to do in
eight (no, not eight thousand lines, eight lines).
On this issue you sound very much like I did in 1999 in regard to
A2K.

That amuses me a great deal.
The computer on which I am writing has Windows and its associated
technologies such as Internet Explorer installed. But it is fully
provisioned with other [FREE] software that is not Microsoft. How
much am I missing Microsoft? Not at all? What have I been unable
to do that I could do with Microsoft ? Not a thing. How many
crashes/ failures have I had with this new software during
February? None. How often and big are the updates? I don't know
because invariably the updates are so simple and swift that I
forget that they happened. I re-installed Windows XP from the
original OEM cds last week and was hit by a total of 113 updates.
One hundred and thirteen! Next I turned on a new Vista computer.
Ah, I thought, they'll be sure to have this very annoying updating
cured. WRONG! Seven updates were required. After three weeks there
were SEVEN F___KING updates required. SEVEN F___KING updates
required after three weeks of availability.
I see that as a *good* thing. MS is releasing patches for
vulnerabilities when they are found, unlike the days when MS would
ignore security issues for months and years. Criticizing MS for
these updates is really counterproductive, in my opinion. MS should
be praised for them.
(Sorry, it seems I have repeated myself) Is this
Microsoft company a JOKE or what?
It's not DAO or ADO that is deficient or dying. They're both great
in Microsoft land. But the rain isn't falling on Microsoft land
much any more. And the soil is drying up. And there are skeletons
on the plains. No one is noticing. But someday soon we will look
at the old vista we remember, and it won't be the same.
I think MS is going to be around at least until I retire. That's at
least 20 years in the future. It won't be the same MS as it is
today, but I'd bet it still has significant market share.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 1 '07 #55
"Larry Linson" <bo*****@localhost.notwrote in
news:OwHFh.4083$Tg7.251@trnddc03:
In the MDB world, I note that the Control
Wizards no longer generate VBA in Access 2007, but generate (the
improved?) macros, instead, and that, I take as some confirmation
of my view of their revised emphasis.
But there was actually a reasonable justification for this: macros
can be executed safely (because of the limited set of available
commands) and VBA code can't.

I still think "fear of VBA in Access" is completely overblown, and
the solution is terrible, but that's the world we live in, where MS
often provides Draconian fixes to problems that don't really exist
to the extent suggested by the seriousness of the fixes.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 1 '07 #56
"David W. Fenton" <XX*******@dfenton.com.invalidwrote
But there was actually a reasonable justification for
this: macros can be executed safely (because of the
limited set of available commands) and VBA code can't.
Help me understand, David, why the VBA code _that is generated by the
wizards_ "can't be executed safely". They haven't done away with VBA, they
have just done away with the Wizards generating it -- you can create your
own event procedures using VBA, but, if you are a developer and going to
extend an event procedure, you are going to have to rewrite what they did
with the *&$% macros.

Do I think they have an agenda to eliminate VBA? Yes, indeed I do, unless
they have a groundswell of support from _enterprise customers_. VSTO is
already there to encourage Word and Excel developers to move to the
"wonderful world of DotNet." No amount of bitchin' from "the great Access
unwashed" is likely to have any effect.

Frankly, I've been a developer since before Bill Gates was in Junior High
School, when he was borrowing time on somebody's minicomputer to learn
programming, and much before he founded Microsoft. For me, it's a little
late to have an interest in switching to "user software support" -- that's
for the interns that the company hires from local colleges to support
technical education and scope out promising young new hires.

Larry
Mar 2 '07 #57
"Larry Linson" <bo*****@localhost.notwrote in
news:AbKFh.6749$tR1.5580@trnddc05:
Frankly, I've been a developer since before Bill Gates was in Junior
High School, when he was borrowing time on somebody's minicomputer to
learn programming, and much before he founded Microsoft. For me, it's
a little late to have an interest in switching to "user software
support" -- that's for the interns that the company hires from local
colleges to support technical education and scope out promising young
new hires.
C'mon Larry. I think you'd be a natural for call-in support. You already
speak a dialect that almost no one can understand (Texan), don't you?
That's a requirement, I believe.
Mar 2 '07 #58
On Mar 1, 9:25 pm, "Larry Linson" <boun...@localhost.notwrote:
The "poor old fellow" has been taken in to the Access
assisted-living facility and is being nursed along with occasional doses of
Software Growth Hormone (e.g., the support for ACCDB)
LOL! Thanks for the vivid image, I like it!

I'm picturing an even more doddery old fellow (DAO) being assigned the
workload of the other guy and being regularly bewildered and
grumbling, "What the heck are CHECK constraints?" "Asynchronous?!!"
etc

Jamie.

--
Mar 2 '07 #59

On Mar 1, 11:27 pm, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
It didn't take a genius to understand that the recommendation by MS
to use ADO with Jet data was a mistake.
ADO with Jet data may have been a mistake but it happened. Sorry!
Wouldn't it be nice if we could rewrite history...

In the late 90s MSFT decided on a major revision of (Access2000)
including a new version of the engine (Jet 4.0) and had a dilema about
whether the native data access technology, DAO, could be enhanced to
support the new engine features because it has 'known issues' with its
architecture e.g. if you don't explicitly teardown objects *and* in
the correct order you will get memory leaks. The SQL Server team, who
had rewritten the Jet engine, had a new data access technology (ADO)
that was generalized enough to support 95% (or better) of Jet. But
MSFT decides to bite the bullet and invest in significantly
restructuring of DAO to make it more robust and to have a flatter
hierarchy (e.g. stand-alone recordsets), support the new Jet features
(e.g. row-level locking) including those not exposed in the Access
user interface (e.g. CHECK constraints), introduce some new properties
(e.g. paging) and methods (e.g. saving recordsets in XML format), plus
introducing events (e.g. asynchronous execution/fetching), including
an 'information schema' to be more in line with the SQL-92 standard,
plus some 'cool' features which were never going to appeal to the old
guard (e.g. hierarchical recordsets). In this version of reality,
would these features have enjoyed better take up? Let's say take up
was the same and eight years on self-styled experts were still unaware
of Jet's CHECK constraints (sorry!). Even then, would the Access
community find it acceptable to be expected to rollback to the Access
97 feature set plus just a handful of the new engine's capabilities? I
think not and, getting back to reality, that's why I say ADO will
remain relevant until DAO functionality has been significantly
enhanced (even if they don't ever fix the architecture).

Many people tried ADO with Jet and liked it. Sorry!

Jamie.

--
Mar 2 '07 #60
"lyle fairfield" <ly******@yahoo.cawrote
C'mon Larry. I think you'd be a natural for call-in
support. You already speak a dialect that almost
no one can understand (Texan), don't you?
That's a requirement, I believe.
Doan chall drawl, tew?

Larry
Mar 2 '07 #61
"Larry Linson" <bo*****@localhost.notwrote in
news:AbKFh.6749$tR1.5580@trnddc05:
"David W. Fenton" <XX*******@dfenton.com.invalidwrote
But there was actually a reasonable justification for
this: macros can be executed safely (because of the
limited set of available commands) and VBA code can't.

Help me understand, David, why the VBA code _that is generated by
the wizards_ "can't be executed safely".
Because there's no way to mark wizard-generated code as a special
kind of code that can't have anything dangerous in it. Macros are
limited to a finite set of commands. VBA is not.
They haven't done away with VBA, they
have just done away with the Wizards generating it -- you can
create your own event procedures using VBA, but, if you are a
developer and going to extend an event procedure, you are going to
have to rewrite what they did with the *&$% macros.
But is there also not a very easy way to convert the macros to code?
I read something about that on one of the Access blogs (probably
Clint Covington's).
Do I think they have an agenda to eliminate VBA?
No, I don't think they do. At least, not until they can replace it
with a managed-code solution. Remember, a huge portion of Access
itself is written in *Access* and delivered as wizards. If VBA were
removed, then those wouldn't work.
Yes, indeed I do, unless
they have a groundswell of support from _enterprise customers_.
VSTO is already there to encourage Word and Excel developers to
move to the "wonderful world of DotNet." No amount of bitchin'
from "the great Access unwashed" is likely to have any effect.
Does VSTO allow you to write managed code for use in Word and Excel?
If not, then I don't understand how it's a replacement for VBA in
Word and Excel.
Frankly, I've been a developer since before Bill Gates was in
Junior High School, when he was borrowing time on somebody's
minicomputer to learn programming, and much before he founded
Microsoft. For me, it's a little late to have an interest in
switching to "user software support" -- that's for the interns
that the company hires from local colleges to support technical
education and scope out promising young new hires.
There will always have to be a scripting language in Access. The
question is: how full-featured will it be and will it still be able
to use API calls.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 2 '07 #62
On Mar 2, 3:31 pm, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
"Larry Linson" <boun...@localhost.notwrote innews:AbKFh.6749$tR1.5580@trnddc05:
"David W. Fenton" <XXXuse...@dfenton.com.invalidwrote
But there was actually a reasonable justification for
this: macros can be executed safely (because of the
limited set of available commands) and VBA code can't.
Help me understand, David, why the VBA code _that is generated by
the wizards_ "can't be executed safely".

Because there's no way to mark wizard-generated code as a special
kind of code that can't have anything dangerous in it. Macros are
limited to a finite set of commands. VBA is not.
They haven't done away with VBA, they
have just done away with the Wizards generating it -- you can
create your own event procedures using VBA, but, if you are a
developer and going to extend an event procedure, you are going to
have to rewrite what they did with the *&$% macros.

But is there also not a very easy way to convert the macros to code?
I read something about that on one of the Access blogs (probably
Clint Covington's).
Do I think they have an agenda to eliminate VBA?

No, I don't think they do. At least, not until they can replace it
with a managed-code solution. Remember, a huge portion of Access
itself is written in *Access* and delivered as wizards. If VBA were
removed, then those wouldn't work.
Yes, indeed I do, unless
they have a groundswell of support from _enterprise customers_.
VSTO is already there to encourage Word and Excel developers to
move to the "wonderful world of DotNet." No amount of bitchin'
from "the great Access unwashed" is likely to have any effect.

Does VSTO allow you to write managed code for use in Word and Excel?
If not, then I don't understand how it's a replacement for VBA in
Word and Excel.
Frankly, I've been a developer since before Bill Gates was in
Junior High School, when he was borrowing time on somebody's
minicomputer to learn programming, and much before he founded
Microsoft. For me, it's a little late to have an interest in
switching to "user software support" -- that's for the interns
that the company hires from local colleges to support technical
education and scope out promising young new hires.

There will always have to be a scripting language in Access. The
question is: how full-featured will it be and will it still be able
to use API calls.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
I think they do want to eliminate or at least minimize VBA. I also
agree with their reasoning. I still hold to many of the predictions I
made here:

http://groups.google.com/group/comp....32d13cf554de71

I said, among other things:

My concern is still that MS may be trying to put VBA into legacy
mode.
If that happens, so that developers are forced into the DotNet world,
there will be a tremendous loss of efficiency for developers unless
new
techniques for customization are developed. I suspect that the new
XML
tools may be meant to lessen the hit of leaving VBA behind. MS may
be
ready to put VBA on a pedestal and place a spotlight on it as the
development tool of the future. Who knows? I don't see it that way
yet. I'm seeing VBA as being a potential sacrifice to DotNet web
integration. I am going to take Larry's advice seriously and try to
be
prepared for any eventuality. Maybe the PDC 05 didn't talk about VBA
much because it wasn't in yet. I'm still leaning toward the
deliberate
de-emphasis theory. Maybe Access will be dumbed down via a VBA
lobotomy in the future. It doesn't make sense for MS to push VBA
anymore. Besides, some XSLT, C#, and SOAP are good for the soul
until
we find out how MS really intends to do RAD.

Comments from PDC05 on WCF:

And we observed that, in most cases, enterprises that are very
successful in taking heterogeneous environments and having them work
in a cohesive way do messaging. And they do something very
important. They do Protocol Integration. That's the way they put
things together. They don't stick everything in one system or inside
of one database. They just have messages flow between one system to
another system. And we committed ourselves at that time, seeing that
observation, to doing WCF. And we also committed ourselves at that
time to doing full blown interop. That's when we sort of flipped the
switch and said, "You know what? We're going to talk to everybody."
....
SOAP enables rich extensibility and security.
....
Application Protocols: POX [Plain Old XML], RSS, ...
Infrastructure Protocols: SOAP, WS-*, ...
....
XML is one of our core architectural commitments.
....
But the key thing is Protocol Integration, XML and then avail yourself
of either Metadata or SOAP as appropriate. But that's where we're
betting as a company, on the fact that protocols are important and
we've got a lot of investment in WS-* and we're going to continue to
do that and we believe that's the center of gravity for us moving
forward.
....
XML, XML, XML, XML.

-- Douglas Purdy, COM 326, PDC05

James A. Fortune
CD********@FortuneJames.com

Mar 4 '07 #63

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.