Google Answers Logo
View Question
 
Q: VB6 vs. Access (VBA) ( No Answer,   9 Comments )
Question  
Subject: VB6 vs. Access (VBA)
Category: Computers > Programming
Asked by: jstm-ga
List Price: $30.00
Posted: 11 Mar 2005 11:03 PST
Expires: 10 Apr 2005 12:03 PDT
Question ID: 492706
I would like to sell the idea to make a program in Visual Basic 6
rather then using Microsoft Access. I need the pros and cons for using
each. I would like a listing of things that can be accomplished using
VB6 that can not be done with Access. The program will be used to
report production by operators in a manufacturing plant.
Answer  
There is no answer at this time.

Comments  
Subject: Re: VB6 vs. Access (VBA)
From: ironbox-ga on 11 Mar 2005 11:23 PST
 
What Is Visual Basic for Applications?


Microsoft Visual Basic for Applications (VBA) is a powerful
development technology for rapidly customizing rich-client desktop
packaged applications and integrating them with existing data and
systems. VBA offers a sophisticated set of programming tools based on
the Microsoft Visual Basic development system, the world's most
popular rapid application development system, which developers can use
to harness the power of packaged applications. VBA enables customers
to buy off-the-shelf software and customize it to meet their specific
business processes, rather than build solutions from scratch. This
helps them save time and money, reduce risks, leverage their
programming skills, and deliver precisely what users need.

Visual Basic for Applications provides a complete integrated
development environment (IDE) that features the same elements familiar
to developers using Microsoft Visual Basic, including a Project
Window, a Properties Window, and debugging tools. VBA also includes
support for Microsoft Forms, for creating custom dialog boxes, and
ActiveX Controls, for rapidly building user interfaces. Integrated
directly into a host application, VBA offers the advantages of fast,
in-process performance (up to 200 times faster than other stand-alone
development tools), tight integration with the host application (code
behind documents, cells, and so forth), and the ability to build
solutions without the use of additional tools.

Software programs that include VBA are called customizable
applications?applications that can be tailored to fit specific
business needs. This class of applications enables developers to
quickly build solutions that require less end-user training. For MIS
and business managers, customization means that solutions can be
developed quickly and deployed easily, with minimal maintenance. In an
industry familiar with two-year backlogs for new applications and high
end-user training costs, these solutions provide a tremendous business
benefit in terms of return on investment (ROI) and timeliness.




--------------------------------------------------------------------------------

Benefits of Visual Basic for Applications Licensing


The increasing number of VBA-enabled applications provides
opportunities for greater application customization and integration by
developers, allowing them to leverage their investments in training in
and knowledge of Visual Basic. Ultimately, these developer benefits
extend to the organizations and users who select VBA-enabled
applications over "build from scratch" solutions. Additional benefits
are outlined here:


Benefits to ISVs

Integrated, award-winning technology.

Licensing Visual Basic for Applications (VBA) enables ISVs to
concentrate on their core competency, rather than on language
development. It enables them to offer customers an award-winning
development environment, and means that ISVs don't have to build
proprietary technologies with differing tools and languages.

Competitive advantage.

Visual Basic for Applications delivers a competitive advantage for
ISVs seeking to provide full customization and integration
capabilities to customers. With VBA-enabled products, ISVs can build
broad capabilities into their core product while providing a
technology for customers to tailor the application and add features
and functionality specific to their requirements.

Simplified and extended applications.

VBA provides ISVs with a way to build VBA-based wizards directly into
their products to walk users through simple or complex operations.
After products ship, VBA enables ISVs to provide Web-based updates to
the core application, delivering new features and functionality
between product cycles.

Macro Recording.

With VBA and Macro Recording, ISVs can provide a simple way for end
users to automate repetitive tasks while providing developers with an
easy way of learning the application programming model.

An enormous developer community.

By licensing Visual Basic for Applications, ISVs can take advantage of
the 3.2 million developers already familiar with the Visual Basic
programming technology who can use an ISV's packaged applications as
development platforms. ISVs can also take advantage of the large
infrastructure already in place for Visual Basic:

Training facilities 
Support centers 
Books and magazines 
Seminars 
Events 
Trade shows 
Thousands of ActiveX Controls 
Web sites
ISVs investing in VBA can extend their applications and deliver the
tools for meeting customers' specific demands. VBA-enabled products
impact the bottom line by providing a built-in customization
technology, enabling customers to pursue a "buy and customize"
alternative to building applications from scratch.

    

Benefits to Developers

Each VBA-hosted application exposes its functionality through an
object model, expanding the ActiveX-based component set available for
developers to use as building blocks for custom solutions.
Developers can become more marketable because they can use their skill
set across many applications.
The ability to reuse code is an immediate advantage because the same
Visual Basic is used everywhere.
Visual Basic for Applications enables customization of applications to
provide solutions tailored to customers' needs.
With the increasing availability of VBA-enabled applications,
developers can now integrate these applications to share data and
information more easily and seamlessly.
Perhaps most dramatically, Visual Basic for Applications enables
developers to build solutions that previously were cost-prohibitive,
because functionality is now available through the integration of
different applications or from different vendors.
With VBA available across a broad range of applications, developers
can customize and integrate line-of-business applications while
leveraging their existing skill set.

    

Benefits to MIS Managers

Developer knowledge can be used across a broad range of applications. 
MIS managers can choose to buy instead of build, while enabling
application customization to meet specific business requirements.
MIS managers can adapt to changing resource requirements by taking
advantage of the huge number of developers skilled in Visual Basic
(over 3.2 million worldwide).
The backlog of end-user application demands can be reduced through
code reuse, resulting in a faster response.
Developers can be moved across development projects easily. 
Visual Basic for Applications can also play a large role in helping
MIS managers and their companies lower training costs by reducing the
number of development environments or languages in which their
developers need to be trained.

    

Benefits to End Users of Application-Based Solutions

Solutions perform faster, thanks to tight integration between VBA and
host applications.
Solutions look and work like the applications users already know, so
less training is required.
Solutions can be user-customized, with respect to print options or
query creation, for example.
There is greater participation in the solution design process?users
can create the output, reports, and documents that they want
automatically generated.
Overall, users will benefit the most from improved solution quality
and customized functionality, as the applications they use today
incorporate richer functionality and integration, and are tailored to
meet their needs.
 




--------------------------------------------------------------------------------

Visual Basic for Applications Version 6.3


With the release of VBA 6.3 in March 2001, Microsoft has built on the
power of VBA 6.0, and has included new features that extend the power,
flexibility, and security of the development environment. This has
opened the door for new ISVs to develop even more powerful solutions
using new features, such as multithreaded VBA-based projects,
developer productivity add-ins, and support for digital signatures.
And with new integration technologies built by Microsoft, ISVs can
integrate VBA into their applications more quickly and easily than
ever.

Visual Basic for Applications 6.3 is a core component of Microsoft
Office XP (it's now in the Microsoft Outlook messaging and
collaboration client and the FrontPage Web site creation and
management tool, as well as Microsoft Access, Microsoft Excel,
Microsoft Word, and the Microsoft PowerPoint presentation graphics
program). Through the VBA licensing program, Microsoft is making the
same version of Visual Basic for Applications in Microsoft Office
broadly available for use in non-Microsoft applications, providing the
same ease of use and power of Visual Basic to a broad range of new
applications.




--------------------------------------------------------------------------------

How Does Visual Basic for Applications Fit with Other Microsoft Tools?


Microsoft offers a number of development tools aimed at specific
developer skills and needs. These include the Microsoft Visual C#,
Microsoft Visual C++, Microsoft Visual J++, and Microsoft Visual
FoxPro development systems; Microsoft Office Developer; and the Visual
Basic family: Visual Basic .NET, Visual Basic for Applications, and
Visual Basic Scripting Edition (VBScript). Tools such as Visual C#,
Visual C++, Visual J++, Visual FoxPro, and the Visual Basic
programming system support developers who build their solutions from
scratch to meet highly specific market needs. Microsoft Office
Developer and Visual Basic for Applications support those developers
who choose to buy and customize packaged applications rather than
build from scratch. Buying and customizing off-the-shelf software
reduces the cost and time of solution development when compared with
building from scratch. The Visual Basic family is designed to offer
powerful programming capabilities based on an easy-to-learn and
easy-to-use programming language.

Each member of the Visual Basic family also has specific uses.
VBScript is designed to offer lightweight scripting capabilities for
low-memory environments, such as Web browsers, and is most commonly
used in creating HTML Web pages. Visual Basic is the world's most
popular rapid-application development tool for creating stand-alone
software components, including executable programs, ActiveX Controls,
and COM components. Finally, Visual Basic for Applications takes the
same power available through the Visual Basic programming system and
applies it to highly functional applications, enabling infinite levels
of automation, customization, and integration.


Access may stop responding when you preview a report
Article ID : 824181 
Last Review : July 29, 2004 
Revision : 1.0 
This article applies only to a Microsoft Access project (.adp). 

Moderate: Requires basic macro, coding, and interoperability skills. 


On this page
 SYMPTOMS 
 CAUSE 
 WORKAROUND 
 REFERENCES 

SYMPTOMS
If you try to preview a report that is grouped on one or more fields
that have many unique values in a Microsoft Access database project,
Access may stop responding, and the preview window may display the
status as Formatting Page.

Note You may still be able to print the problem report successfully.
CAUSE
This problem occurs when the report is based on a very large recordset
and the report is grouped on the fields in the recordset that contain
many unique values (in the thousands).
WORKAROUND
To work around this problem, do not preview the report directly in
Access if the report is based on a large recordset. Instead, you can
use a smaller recordset when you design and preview the report, and
then you can switch to the full recordset when you are ready to print
the report.
REFERENCES
For more information about how to group and sort in a report, click
Microsoft Office Access Help on the Help menu, type Change sorting and
grouping levels in the Search for box in the Assistance pane, and then
click Start searching to view the topic.

--------------------------------------------------------------------------------
How to automate the process of selecting the printer for a report in
Microsoft Access
Article ID : 319317 
Last Review : February 22, 2005 
Revision : 6.0 
This article was previously published under Q319317
Novice: Requires knowledge of the user interface on single-user computers. 

This article applies only to a Microsoft Access database (.mdb). 


On this page
 SUMMARY 
 MORE INFORMATION 
 REFERENCES 

SUMMARY
If you want to print a report to a particular printer, you can
manually select the printer and all of the print options, or you can
automate the process so that with a click of a button, you can switch
printers and then print your report with the options that you
predefine. This article explains how to automate the process of
printer selection.
MORE INFORMATION
This procedure uses two examples: printing to a laser printer and
printing to a dot-matrix printer. You can substitute the particular
printers that you want to use. To automate the process of printer
selection for a particular report, follow these steps: 1. Create the
following three reports:

? rptLaserPrinter 
? rptDotMatrix 
? rptMyReport 


NOTE: rptMyReport represents the actual report that you want to print. 
2. To set the printer options, follow these steps: a.  Open
rptLaserPrinter in Design view.
b.  On the File menu, click Print. 
c.  In the Name box, click the laser printer that you want to use. 
d.  Click Properties, set any print options that you want, such as the
orientation and paper size, and then click OK.
e.  Repeat steps a through d for rptDotMatrix. Click the dot-matrix
printer in step c.
 
3. In the Database window, click Modules, click New, and then type the
following function:

Function ChangePrinter(rptToChange As String, rptPrinter As String)

   Dim rpt1 As Report, rpt2 As Report

   DoCmd.OpenReport rptToChange, acViewDesign
   DoCmd.OpenReport rptPrinter, acViewDesign

   Set rpt1 = Reports(rptToChange)
   Set rpt2 = Reports(rptPrinter)

   rpt1.PrtDevNames = rpt2.PrtDevNames

   DoCmd.Close acReport, rptPrinter, acSaveNo
   DoCmd.OpenReport rptToChange, acViewPreview
End Function
						
NOTE: The ChangePrinter function copies the PrtDevNames property from
one report to another. You can then copy the print options that you
set for the rptLaserPrinter and rptDotMatrix reports to a specific
report that you want to print.

NOTE: The "acSaveNo" property is used in the "DoCmd.Close acReport,
rptPrinter, acSaveNo" line of the code that is shown earlier in this
section. If you do not use this option and you save the PrtDevName of
a nondefault printer to the report design, the report will not be able
to find the printer when it runs the next time. You will receive the
following error message:
This document was previously formatted for the printer <PrinterName>
on <Port>; but that printer isn't available. Do you want to use the
default printer <DefaultPrinterName> on <Port>?
4. Save the module as Module1, and then quit the Visual Basic Editor. 
5. Create the following form:   Form: frmForm1
   ------------------------------
      RecordSource: Unbound

   Control Type: Command Button
      Name: cmdLaser
      Caption: Laser
   Control Type: Command Button
      Name: cmdDotMatrix
      Caption: Dot Matrix
					
 
6. On the View menu, click Code. 
7. In the Visual Basic Editor, type the following procedures:Private
Sub cmdLaser_Click ()

  Call ChangePrinter("rptMyReport", "rptLaserPrinter")
  DoCmd.PrintOut

End Sub

Private Sub cmdDotMatrix_Click ()

  Call ChangePrinter("rptMyReport", "rptDotMatrix")
  DoCmd.PrintOut

End Sub
					
 
8. Quit the Visual Basic Editor, and then change the On Click property
of both command buttons to [Event Procedure]. To do so, follow these
steps: a.  In Design view, click the command button, and then click
Properties on the View menu.
b.  Click the Event tab, click the On Click property, click the down
arrow, and then click [Event Procedure].
 
9. To print rptMyReport to a specific printer, open frmForm1 in Form
view, and then click the appropriate button.
BUG: A control on a form or on a report that refers to a control on a
subform or on a subreport is blank in Access 2003
Article ID : 883867 
Last Review : August 20, 2004 
Revision : 1.0 

This article applies to a Microsoft Access database (.mdb) and a
Microsoft Access project (.adp).

Moderate: Requires basic macro, coding, and interoperability skills. 

On this page
 SYMPTOMS 
 RESOLUTION 
 WORKAROUND 
 STATUS 
 MORE INFORMATION 
 REFERENCES 

SYMPTOMS
When you open a form that contains a subform, you may notice that the
control on the form that refers to the control on the subform is
blank. When you open a report that contains a subreport, you may
notice that the control on the report that refers to the control on
the subreport is blank.

You notice this behavior when the following conditions are true:? The
expression in the ControlSource property for the control on the form
or on the report does not provide a full reference to the control on
the subform or on the subreport, respectively.

For example, to display a value that is calculated in the
OrderSubtotal control on the "Orders" subform, the following
expression is entered as the ControlSource property for the Subtotal
control on the "Orders" main form: =[Orders Subform]!OrderSubtotal
 
? Sandbox mode is turned on for Microsoft Office Access 2003 applications. 

RESOLUTION
To resolve this problem, you must install Microsoft Office 2003
Service Pack 1 on your computer.

The following file is available for download from the Microsoft Download Center:


Office 2003 Service Pack 1
WORKAROUND
To work around this problem, you must modify the ControlSource
property for the control on the form or on the report. You do this to
provide a full reference to the control on the subform or on the
subreport, respectively.

To refer to a control on the subform, you must include the .Form
identifier in the expression that is entered as the ControlSource
property for the corresponding control on the main form.

For example, to display a value that is calculated in the
OrderSubtotal control on the "Orders" subform, you must enter the
following expression as the ControlSource property for the
corresponding control on the "Orders" main form:=[Orders
Subform].Form!OrderSubtotal
Similarly, to refer to a control on the subreport, you must include
the .Report identifier in the expression that is entered as the
ControlSource property for the corresponding control on the main
report.

For example, to display a value that is calculated in the QuarterTotal
control on the "Sales by Year" subreport, you must enter the following
expression as the ControlSource property for the corresponding control
on the "Sales by Year" main report: =[Sales by Year
Subreport].Report!QuarterTotal
STATUS
Microsoft has confirmed that this is a bug in the Microsoft products
that are listed in the "Applies to" section.
MORE INFORMATION
Steps to reproduce the problem
Caution If you follow the steps in this example, you modify the sample
database Northwind.mdb. You may want to back up the Northwind.mdb file
and follow these steps on a copy of the database. 1. Turn on Sandbox
mode for Access 2003 applications. To do this, follow these steps:a. 
Start Access 2003.
b.  On the Tools menu, point to Macro, and then click Security. 
c.  In the Security dialog box, click Medium on the Security Level
tab, and then click OK.
d.  Close Access 2003. 
Note If the macro Security menu item is missing, you must add the menu
item by customizing the toolbar.

For additional information, click the following article number to view
the article in the Microsoft Knowledge Base:
833219 Menu items are missing after you upgrade from an earlier
version of Microsoft Access to Microsoft Office Access 2003
2. Start Access 2003. 
3. Open the Northwind.mdb sample database. 
4. In the Database window, click Forms under the Objects section. 
5. In the right pane, right-click Orders, and then click Design View.

The Orders form opens in Design view. 
6. On the Orders form, locate, and then select the text box that is
named Subtotal.
7. On the View menu, click Properties. 
8. On the Data tab, locate the Control Source property.

Notice that the Control Source property originally contains the
following expression: =[Orders Subform].Form!OrderSubtotal
On the Data tab, modify the expression in the Control Source property
to the following:=[Orders Subform]!OrderSubtotal
 
9. Save the form. 
10. On the View menu, click Form View.

The Orders form opens in Form view.

Notice that the value in the Subtotal box is blank. 

REFERENCES
For more information about Microsoft Jet Expression Service Sandbox
mode, click Microsoft Office Access Help on the Help menu, type about
Microsoft Jet Expression Service Sandbox mode in the Search for box in
the Assistance pane, and then click Start searching to view the topic.

For more information about referring to an object or to its properties
in expressions, click Microsoft Office Access Help on the Help menu,
type refer to objects in expressions in the Search for box in the
Assistance pane, and then click Start searching to view the topic.
Subject: Re: VB6 vs. Access (VBA)
From: jstm-ga on 11 Mar 2005 13:19 PST
 
Is there no advantage to using Visual basic 6 instead of Access?

Can Access communicate with PLC's?
Subject: Re: VB6 vs. Access (VBA)
From: willcodeforfood-ga on 11 Mar 2005 14:53 PST
 
Microsoft Access solution will require that each client workstation
have a licensed copy of Access on that workstation.  Visual Basic will
use the VB runtime so no per-workstation costs.

Microsoft Access application files tend to become corrupted and then
start giving weird errors.  Most of the time the application file must
be overwritten with a fresh copy to resolve.  Compact and repair does
not always do it.

If you are using forms in Microsoft Access, you will find that their
performance is terrible once the underlying tables grow very large. 
Anything beyond 10K records will start to have issues.  Linking to SQL
Server tables will help, but will slow down at 50K records or so.

If you start using Access, you will find that your codebase will
become written in DAO.  If you ever decide that the application needs
to be web-based or more robust, most of the entire project will be a
rewrite.  VB will use ADO, which can be more easily ported to ASP, or
.NET based systems.

Microsoft forms use DAO to access data.  This protocol is
excrutiatingly slow when running across a slow link or wide-area
network.

If you have each user run their own copy of the Access application
file, then you'll have to redistribute a new entire copy to each user
every time you make any change to the application file.  You can get
around this, but you'll have to write support utilities to copy form
and report objects from a repository.  With this scenario, you'll
eventually have more than one application version running against the
same database.

If you have each user run a central copy of the Access application
file, then you'll have to ask everyone to get out of the file befpre
you can overwrite with a newer one.  If someone forgets and leaves
your system running and locks a workstation, you'll have to find it
and shut it off before you can overwrite the application file.  Worse
yet, if they kill their system by doing a hard power-off (or the power
flickers), you'll need to reboot the computer where the Access
application resides before you can overwrite the application file.

To have any real data security, you have to use inegrated windows
authentication.  Now every time you need to add or remove a user,
someone has to open SQL Server and create/modify/delete a SQL user
account.  If you are using Access' built-in security, then you are in
for some rough weather ahead.  The Access built in security is a pain
to implement and not really all that secure anyway.  Security is still
challenging to properly implement with VB, but not the nightmare that
Access can be.

If you ever want to package the system up for resale or reuse (say by
business partners or other internal divisions) and you want to NOT
release the source code, it has to be in VB.  Access always includes
source code.  Access does make run-time only application databases,
but they can't have linked tables and theses files come with their own
set of problems.

One of the only real advantages to Access is that it has built in
basic reports.  Of course if you want highly customized reports,
you'll quickly abandon Microsoft reports anyway.

Access forms do not support designs that are not a direct tranlation
of their underlying data.  As such, you end up designing the database
to support the limited functionality of forms, rather than properly
normalizing the data.  When you rewrite the system, you inherit these
same problems into the new system.  Here's what I mean.

Emps         EmpRoles      Roles            Here's how you might
======       =======       ========     <-- want to control user
EmpID  ----- EmpID         RoleDescr        access to code modules
LastName     RoleID  ----  RoleID
FirstName

And here's what you want the form to look like:
                      
Last Name   First Name      SysAdmin   Billing   DataEntry   Payroll
=========   ==========      ========   =======   =========   =======
Jones       Jenny              X
Peterson    Patty                                               X
Smith       Samuel                        X          X

And while I'd agree that VB doesn't do a great job of supporting this
type of functionality, Access couldn't do this unless you dedicated
your life to the project.  In the end, you'll build a table like this:

Emps
======
EmpID
LastName
FirstName          <-- Yuck!
IsAdmin
IsBilling
IsEntry
IsPayroll

If you really want to be able to design the interface so that it can
look radically different than the underlying data design, I'd go with
a web interface, but VB is at least a lot better than Access for this
sort of thing.

If you have a small budget and only need a few screens and reports,
have no large data storage requirements, aren't terribly concerned
about security, and are going to have all your users on the same
netwrok, then Access is fine.

If you are building a production system that will hold important
business information, will be used until a better system can be found,
or uptime is very important, then Access may not be the wise choice.
Subject: Re: VB6 vs. Access (VBA)
From: willcodeforfood-ga on 11 Mar 2005 14:56 PST
 
To answer your followup, if there is any way for any piece of software
to communicate with your PLC, then it will be no harder or easier to
do so with Access or VB.
Subject: Re: VB6 vs. Access (VBA)
From: willcodeforfood-ga on 11 Mar 2005 15:23 PST
 
After reading some of your other posts, I think that maybe what you
are looking for is something like this to help you with the PLC
communication:

[ http://www.automatedsolutions.com/products/commab.asp ]

If you are using one of the models that this company's software
supports, then you'll be glad to read on their site that "ActiveX
evaluations copies include two sample VB applications, source code,
and complete online documentation."

An ActiveX control is a piece of software that VB or Access can "talk"
to.  So if you get an ActiveX control designed to interface your PLC,
then you can use Access or VB to talk through that ActiveX control to
the PLC.
Subject: Re: VB6 vs. Access (VBA)
From: jstm-ga on 11 Mar 2005 16:24 PST
 
Thanks for your help!!!Again...
Subject: Re: VB6 vs. Access (VBA)
From: dreamboat-ga on 11 Mar 2005 17:24 PST
 
>>Microsoft Access solution will require that each client workstation
have a licensed copy of Access on that workstation.  Visual Basic will
use the VB runtime so no per-workstation costs.

I don't think that statement is entirely true. To my knowledge, you
need the Microsoft Office Developer's Edition, and you can create a
runtime Access program. You don't need VB (which could cost you in
programming), and I don't believe runtime versions can be cracked
either. This might help:

http://www.programmingmsaccess.com/FAQs/MOD.htm

I would post its content, but it's copyrighted.
Subject: Re: VB6 vs. Access (VBA)
From: willcodeforfood-ga on 11 Mar 2005 18:50 PST
 
You can install only the runtime portions of Microsoft Access.  I
haven't done it with any recent versions, but remember it being a pain
in older versions of Access.  In the end, we just bought full versions
of Access and gave up on figuring out how to install the runtime
version.

If you write your software in Access and then find that it's not
working right after you use the Office Developer's Version to deploy
it, you may end up buying full versions of Access to get it running as
well.

The runtime version of the Access application database is an MDE file.
 It is fine for keeping users from tampering.  If you want to keep
your code secret, an MDE file is not an effective solution for
securing software that will be distributed outside your business.

Here's an MDE cracker here that offers a free trial version:

[ http://www.eurodownload.com/download-software/5691/Access-MDE-Unlocker.html ]

Some people actually use a hybrid solution.  For example, you create
the administration forms and reports in Access and you are the only
one that uses those screens.  Then you write the screens to be used by
the manufacturing plant operators in VB.  This gives you some
advantages of both and can avoid some of the drawbacks of both
approaches.
Subject: Re: VB6 vs. Access (VBA)
From: dreamboat-ga on 13 Mar 2005 00:19 PST
 
(jstm: sorry for the off-topic comment).

Good info, willcodeforfood. I wish you were hanging around *my*
favorite website. :)

I know you can crack just about anything, but wasn't aware that MDE's could be.

Important Disclaimer: Answers and comments provided on Google Answers are general information, and are not intended to substitute for informed professional medical, psychiatric, psychological, tax, legal, investment, accounting, or other professional advice. Google does not endorse, and expressly disclaims liability for any product, manufacturer, distributor, service or service provider mentioned or any opinion expressed in answers or comments. Please read carefully the Google Answers Terms of Service.

If you feel that you have found inappropriate content, please let us know by emailing us at answers-support@google.com with the question ID listed above. Thank you.
Search Google Answers for
Google Answers  


Google Home - Answers FAQ - Terms of Service - Privacy Policy