are ado questions allowed here?

[MP]

I'm interested to learn how to use mdb files via ado/adox via vb6
Since I'm not using Access are those types of questions o.t. here?
I see very few ado questions here. But there's a lot more traffic here than
the ado groups.
:-)

Thanks
Mark

[Steve Jorgensen]

On Wed, 30 Nov 2005 05:47:14 GMT, "MP" <no****@Thanks.com> wrote:

I'm interested to learn how to use mdb files via ado/adox via vb6
Since I'm not using Access are those types of questions o.t. here?
I see very few ado questions here. But there's a lot more traffic here than
the ado groups.
:-)

If it has to do with MDBs or JET, I'd say it's close enough. Ask away.

[Lyle Fairfield]

Sure they are. And sometimes when the Gestado aren't paying attention,
ADO answers are allowed too.

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:5o********************************@4ax.com:

On Wed, 30 Nov 2005 05:47:14 GMT, "MP" <no****@Thanks.com> wrote:

I'm interested to learn how to use mdb files via ado/adox via vb6
Since I'm not using Access are those types of questions o.t. here?
I see very few ado questions here. But there's a lot more traffic
here than the ado groups.
:-)

If it has to do with MDBs or JET, I'd say it's close enough. Ask
away.

I wouldn't.

Using an MDB from VB is not Access, in any way, shape or form.

But there are likely people who've dealt with the same issues in
Access, so one would likely have a good chance of getting an answer.

But it's important that the questions be asked in a way that makes
it clear that ACCESS is not involved in the question at all.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Larry Linson]

"Lyle Fairfield" <ly***********@aim.com> wrote

Sure they are. And sometimes when the Gestado
aren't paying attention, ADO answers are
allowed too.

Is this something to do with "Much ADO about nothing?" :-)

I was under the impression that ADO answers were allowed only about the
obsolescent "classic ADO" as supported by various versions of Access, not
about the Microsoft's current ADO.NET software which has succeeded classic
ADO, except in Office.

Larry

[Steve Jorgensen]

On Wed, 30 Nov 2005 15:02:37 -0600, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:5o********************************@4ax.com :

On Wed, 30 Nov 2005 05:47:14 GMT, "MP" <no****@Thanks.com> wrote:

I'm interested to learn how to use mdb files via ado/adox via vb6
Since I'm not using Access are those types of questions o.t. here?
I see very few ado questions here. But there's a lot more traffic
here than the ado groups.
:-)

If it has to do with MDBs or JET, I'd say it's close enough. Ask
away.

I wouldn't.

Using an MDB from VB is not Access, in any way, shape or form.

But there are likely people who've dealt with the same issues in
Access, so one would likely have a good chance of getting an answer.

But it's important that the questions be asked in a way that makes
it clear that ACCESS is not involved in the question at all.

I disagree that we have to draw rigid lines of any such sort. In fact, the
OP's question and our answers are probably more disruption than if someone
simply asks a question that might be far afield, and someone responds with an
answer or a suggestion to ask another group if it's too far off. It's easier
to work with specifics than hypotheticals.

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:fi********************************@4ax.com:

On Wed, 30 Nov 2005 15:02:37 -0600, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:5o********************************@4ax.co m:

On Wed, 30 Nov 2005 05:47:14 GMT, "MP" <no****@Thanks.com>
wrote:

I'm interested to learn how to use mdb files via ado/adox via
vb6 Since I'm not using Access are those types of questions o.t.here? I see very few ado questions here. But there's a lot moretraffic here than the ado groups.
:-)

If it has to do with MDBs or JET, I'd say it's close enough.
Ask away.
I wouldn't.

Using an MDB from VB is not Access, in any way, shape or form.

But there are likely people who've dealt with the same issues in
Access, so one would likely have a good chance of getting an
answer.

But it's important that the questions be asked in a way that makesit clear that ACCESS is not involved in the question at all.

I disagree that we have to draw rigid lines of any such sort. . .

How many times do we waste time answering a question as though it's
an Access question, when it turns out that Access is not even being
used? I can usually detect that from the form of the question, but
it's often not obvious at all, and I think it would be *very*
helpful if Microsoft would stop confusing things in its
documentation by treating "Access database" as synomous with "Jet
database." There are a whole host of people out there who don't
know
the difference and because of that, think very poorly of Access as
a
product.
. . . In
fact, the OP's question and our answers are probably more
disruption than if someone simply asks a question that might be
far afield, and someone responds with an answer or a suggestion to ask another group if it's too far off. It's easier to work with
specifics than hypotheticals.

Oh, puh-leaze. Four posts is hardly a distraction, especoally in
the
same week when several dozen posts about one persons's sig have
been
quite prominent in the newsgroup.

I think everyone would be better served by maintaining the clear
distinction between Access and Jet.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

On Wed, 30 Nov 2005 22:38:25 -0600, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

....

How many times do we waste time answering a question as though it's
an Access question, when it turns out that Access is not even being
used? I can usually detect that from the form of the question, but
Ok, that's a valid point.
it's often not obvious at all, and I think it would be *very*
helpful if Microsoft would stop confusing things in its
documentation by treating "Access database" as synomous with "Jet
database." There are a whole host of people out there who don't
know
the difference and because of that, think very poorly of Access as
a
product.
That too.

. . . In
fact, the OP's question and our answers are probably more
disruption than if someone simply asks a question that might be
far afield, and someone responds with an answer or a suggestionto

ask another group if it's too far off. It's easier to work with
specifics than hypotheticals.

Oh, puh-leaze. Four posts is hardly a distraction, especoally in the
same week when several dozen posts about one persons's sig have been
quite prominent in the newsgroup.

That was not to suggest that this thread is a disruption, but that a single
off-topic question with a simple redirection as a response is even less so.
As you pointed out above, that would presume that the communication actually
is that efficient, which is not necessarily so.
I think everyone would be better served by maintaining the clear
distinction between Access and Jet.

Yes, but it would also be a shame to waste the concentration of JET knowledge
here, including a lot of ADO/JET knowledge, just because ADO and non-Access
cleints are dogmatically deemed off-topic. We'd rather have people first ask
a question about whether the question they're -going- to ask is off topic,
whithout even knowing what their specific question will be?

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:9f********************************@4ax.com:

On Wed, 30 Nov 2005 22:38:25 -0600, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

[]

I think everyone would be better served by maintaining the clear
distinction between Access and Jet.

Yes, but it would also be a shame to waste the concentration of
JET knowledge here, including a lot of ADO/JET knowledge, just
because ADO and non-Access cleints are dogmatically deemed
off-topic. We'd rather have people first ask a question about
whether the question they're -going- to ask is off topic, whithout
even knowing what their specific question will be?

Steve, did you actually read the whole of my original response in
this thread?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[MP]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message

I think everyone would be better served by maintaining the clear
distinction between Access and Jet.

Gentlemen,
I have watched with interest the answers to my orig question.
Thank you all for your consideration.
I will continue lurking here as I can learn quite a bit from information
which are of a general sql query nature,
rather than specifically about Access objects/forms etc.
I will try to restrict my ado/Jet questions to one of the two ado groups I
have available on my newsserver.
Thanks,
Mark

[Lyle Fairfield]

MP wrote:

I will try to restrict my ado/Jet questions to one of the two ado groups I
have available on my newsserver.

That's disappointing.

[pietlinden]

Sorry, the great and powerful thought police of CDMA have spoken. pay
no attention to the man behind the curtain. If he really doesn't want
to answer your question, he can choose not to.

[Randy Harris]

"MP" <no****@Thanks.com> wrote in message
news:FR****************@tornado.rdc-kc.rr.com...

"David W. Fenton" <dX********@bway.net.invalid> wrote in message

>I think everyone would be better served by maintaining the clear
>distinction between Access and Jet.

Gentlemen,
I have watched with interest the answers to my orig question.
Thank you all for your consideration.
I will continue lurking here as I can learn quite a bit from information
which are of a general sql query nature,
rather than specifically about Access objects/forms etc.
I will try to restrict my ado/Jet questions to one of the two ado groups I
have available on my newsserver.
Thanks,
Mark

Mark,

I wish you wouldn't avoid cdma simply because of the conversation in this
thread. This ng is a marvelous resource. There are many, many people who
contribute with an incredibly broad range of knowledge and experience. Post
your questions, I believe that you will be pleasantly surprised.

My 2 cents worth,
Randy Harris

[rkc]

MP wrote:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message

I think everyone would be better served by maintaining the clear
distinction between Access and Jet.

Gentlemen,
I have watched with interest the answers to my orig question.
Thank you all for your consideration.
I will continue lurking here as I can learn quite a bit from information
which are of a general sql query nature,
rather than specifically about Access objects/forms etc.
I will try to restrict my ado/Jet questions to one of the two ado groups I
have available on my newsserver.

Ask any question you want to.

[Steve Jorgensen]

On Thu, 01 Dec 2005 14:22:16 -0600, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:9f********************************@4ax.com :

On Wed, 30 Nov 2005 22:38:25 -0600, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

[]

I think everyone would be better served by maintaining the clear
distinction between Access and Jet.

Yes, but it would also be a shame to waste the concentration of
JET knowledge here, including a lot of ADO/JET knowledge, just
because ADO and non-Access cleints are dogmatically deemed
off-topic. We'd rather have people first ask a question about
whether the question they're -going- to ask is off topic, whithout
even knowing what their specific question will be?

Steve, did you actually read the whole of my original response in
this thread?

I had, and I had forgotten it. I was responding to the tail of the thread.
Going back to that, I see why you are asking this question. Mea culpa.

[Lyle Fairfield]

"Larry Linson" <bo*****@localhost.not> wrote in
news:sBojf.5220$3x2.1886@trnddc07:

"Lyle Fairfield" <ly***********@aim.com> wrote

Sure they are. And sometimes when the Gestado
aren't paying attention, ADO answers are
allowed too.

Is this something to do with "Much ADO about nothing?" :-)

I was under the impression that ADO answers were allowed only about
the obsolescent "classic ADO" as supported by various versions of
Access, not about the Microsoft's current ADO.NET software which has
succeeded classic ADO, except in Office.

Larry

Microsoft re MDAC

Introduction

This article describes the past, present, and future of Microsoft data
access technologies, including DB-Library, ESQL, DAO, Microsoft® Data
Access Components (MDAC) (including ODBC, ADO, and OLE DB), ADO.NET, and
SQL Native Client. This article identifies which technologies are being
enhanced, and which technologies and components are being deprecated or
excluded from future releases.
Microsoft Data Access Components (MDAC)

With Microsoft Data Access Components (MDAC), developers can connect to
and use data from a wide variety of relational and non-relational data
sources. You can connect to many different data sources using ActiveX®
Data Objects (ADO), Open Database Connectivity (ODBC), or OLE DB. You can
do this through providers and drivers that are either built and shipped
by Microsoft, or that are developed by various third parties.
Current MDAC Architecture

With the current MDAC architecture, client-server, n-tier, or Web browser
applications can access SQL, Semi-Structured, and Legacy Data stores.
Additionally, with MDAC (depending on requirements), these applications
have the flexibility to access the data using ADO, OLE DB, or ODBC.

Figure 1. Current MDAC architecture

For the purposes of this document, you can divide the MDAC stack into the
following components, based on technology and products:

* ADO (Including ADOMD and ADOX)
* OLE DB (including SQL Server OLE DB Provider, Oracle OLE DB
Provider, OLE DB Provider for ODBC Drivers, Data Shape Provider, and
Remote Data Provider)
* ODBC (including SQL ODBC Driver and Oracle ODBC Driver)

Current MDAC Components

These components are supported in the current release. Use these
components when you develop new applications or upgrade existing
applications.

* ADO: ActiveX Data Objects (ADO) provides a high-level programming
model that will continue to be enhanced. Although a little less
performant than coding to OLE DB or ODBC directly, ADO is straightforward
to learn and use, and can be used from script languages such as Microsoft
Visual Basic® Scripting Edition (VBScript) or Microsoft JScript®.
* ADOMD: ADO Multi-Dimensional (ADOMD) is to be used with multi-
dimensional data providers such as Microsoft OLAP Provider, also known as
Microsoft Analysis Services Provider. No major feature enhancements have
been made to it since MDAC 2.0; however, it will be available on the 64-
bit Microsoft Windows® operating system.
* ADOX: ADO Extensions for DDL and Security (ADOX) enables the
creation and modification of definitions of a database, a table, an
index, or a stored procedure. You can use ADOX with any provider. The
Microsoft Jet OLE DB Provider provides full support for ADOX, while the
Microsoft SQL OLE DB Provider provides limited support. No major
enhancements are planned for ADOX in future MDAC releases; however, it
will be available on the 64-bit Windows operating system.
* OLE DB: OLE DB is a comprehensive set of COM interfaces for
accessing a diverse range of data in a variety of data stores. OLE DB
providers exist for accessing data in databases, file systems, message
stores, directory services, workflow, and document stores. OLE DB core
services (though not every OLE DB provider) will be available on the 64-
bit Windows operating system.
* SQLOLEDB: Microsoft OLE DB Provider for SQL Server (SQLOLEDB)
supports access to Microsoft SQL Server 6.5 and later. This OLE DB
Provider will be the primary focus of future MDAC feature enhancements.
It will be available on the 64-bit Windows operating system.
* Microsoft SQL Server Network Libraries: The SQL Server Network
Libraries allow SQLOLEDB and SQLODBC to communicate with the SQL Server
database. The following SQL Server Network Libraries are currently
deprecated in MDAC releases: Banyan Vines, AppleTalk, Servernet, IPX/SPX,
Giganet, and RPC. TCP/IP, Named Pipes, and Shared Memory SQL Server
Network Libraries will continue to be enhanced and will be available on
the 64-bit Windows operating system.
* ODBC: The Microsoft Open Database Connectivity (ODBC) interface is
a C programming language interface that allows applications to access
data from a variety of Database Management Systems (DBMS). Applications
using this API are limited to accessing relational data sources only.
ODBC will be available on the 64-bit Windows operating system.
* SQLODBC: Microsoft SQL Server ODBC Driver (SQLODBC) enables access
to Microsoft SQL Server 6.5 and later. SQLODBC will be available on the
64-bit Windows operating system.

Deprecated MDAC Components

These components are still supported in the current release of MDAC, but
might be removed in future releases. Microsoft recommends that when you
develop new applications, you avoid using these components. Additionally,
when you upgrade or modify existing applications, remove any dependency
on these components.

* Jet: Starting with version 2.6, MDAC no longer contains Jet
components. In other words, MDAC 2.6, 2.7, 2.8, and all future MDAC
releases do not contain Microsoft Jet, Microsoft Jet OLE DB Provider, or
the ODBC Desktop Database Drivers.
* MSDASQL: The Microsoft OLE DB Provider for ODBC (MSDASQL) provides
ADO clients access to databases through ODBC Drivers. This has been the
default provider for ADO; however, for future releases of MDAC and the
64-bit Windows operating system, MSDASQL has been deprecated. Therefore,
to access the database from ADO, clients must use appropriate Native OLE
DB Providers, such as SQLOLEDB, to access Microsoft SQL Server. MSDASQL
will be not available on the 64-bit Windows operating system; however, it
will still be possible to use on the 64-bit Windows operating system
through the 32-bit Windows subsystem.
* MSDADS: With the Microsoft OLE DB Provider for Data Shaping
(MSDADS), you can create hierarchical relationships between keys, fields,
or rowsets in an application. No major feature enhancements have been
made since MDAC 2.1. This Provider has been deprecated in future MDAC
releases. Microsoft recommends that you use XML instead of MSDADS.
* Oracle ODBC: The Microsoft Oracle ODBC Driver (Oracle ODBC)
provides access to Oracle database servers. It provides full support for
Oracle 7. It also uses Oracle 7 emulation to provide limited support for
Oracle 8 databases. The Oracle ODBC Driver has not been tested with
Oracle 9 databases.
* MSDAORA: The Microsoft Oracle OLE DB Provider (MSDAORA) provides
access to Oracle database servers. It provides full support for Oracle 7.
It also uses Oracle 7 emulation to provide limited support for Oracle 8
databases. The Oracle OLE DB Provider has not been tested with Oracle 9
databases. A 64-bit version of this provider will not be available on the
64-bit Microsoft Windows® operating system.
* RDS: Remote Data Services (RDS) is a proprietary Microsoft
mechanism to access remote ADO Recordset objects across the Internet or
an intranet. No major feature enhancements have been made to RDS since
MDAC 2.1. This component is being deprecated. Microsoft now ships the
Microsoft SOAP Toolkit 2.0, in which applications can access remote data
by using an open, XML-based standard. Applications that use RDS should
migrate to SOAP.
* JRO: The Microsoft Jet OLE DB Provider and other related components
have been removed from the MDAC stack since MDAC 2.6. Jet Replication
Objects (JRO) is used only with Jet (Access) databases, basically to
create or compact the Jet Database and Jet Replication Management. JRO
has been deprecated and MDAC 2.7 will be its last release. It will not be
available on the 64-bit Windows operating system.
* SQL XML: SQL XML provides extensions to Microsoft OLE DB Provider
for SQL Server (SQLOLEDB) to allow clients to request Microsoft SQL
Server 2000 data through XML, and to retrieve XML streams. It was first
released with MDAC 2.6. With SQL XML Web Release 1, clients can insert,
update, and delete data in SQL Server 2000 using Updategrams and Bulk
Load. This component is not being deprecated, but it is being removed
from future MDAC releases. Current and later versions of this product are
available as Web downloads. SQL XML will be available on the 64-bit
Windows operating system.

MDAC Releases

Here is a list of the supportability scenarios of past, present, and
future MDAC releases, starting with the earliest.

* MDAC 1.5, MDAC 2.0, and MDAC 2.1: These versions of MDAC were
independent releases that were released through the Microsoft Windows NT®
Option Pack, the Microsoft Windows Platform SDK, or the MDAC Web site.
These versions of MDAC are no longer supported.
* MDAC 2.5: This version of MDAC was included with the Windows 2000
operating system. Future services packs of MDAC 2.5 will be included with
corresponding Windows 2000 service packs. Additionally, these MDAC
services packs will be released to the MDAC Web site in accordance with
the Windows 2000 service pack release schedule. You can only install this
version of MDAC on Windows NT, Windows 95, and Windows 98 platforms. You
can only install this version on Windows 2000 and Windows Millennium
Edition platforms through the operating systems or their services packs.
This version is currently supported.
* MDAC 2.6: MDAC 2.6 RTM, SP1, and SP2 were included with Microsoft
SQL Server 2000 RTM, SP1, and SP2, respectively. Additionally, these MDAC
service packs were released to the MDAC Web site in accordance with the
Microsoft SQL Server 2000 service pack release schedule. You can install
this version of MDAC and its service packs on Windows 2000, Windows
Millennium Edition, Windows NT, Windows 95, and Windows 98 platforms.
This version is no longer supported.
* MDAC 2.7: This version of MDAC is included with the Microsoft
Windows XP RTM and SP1 operating systems. You can install this version of
MDAC and its service packs on Windows 2000, Windows Millennium, Windows
NT, and Windows 98 platforms. You can only install this version on the
Windows XP platform through the operating system or its services packs.
o The 32-bit version of MDAC 2.7 has been released to the MDAC
Web site.
o The 64-bit version of MDAC 2.7 will release with the 64-bit
version of Windows XP only.
* MDAC 2.8: This version of MDAC is included with Windows Server 2003
and Windows XP SP2 and later.
o The 32-bit version of MDAC 2.8 will also be released to the
MDAC Web site at the same time Windows Server 2003 is released to the
customer.
o The 64-bit version of MDAC 2.8 will release with the 64-bit
version of Windows Server 2003 only.

SQL Native Client (SQLNCLI)

SQL Native Client (SQLNCLI) is a data access technology that is new to
Microsoft SQL Server 2005, and it is a stand alone data access
Application Programming Interface (API) that is used for both OLE DB and
ODBC. It combines the SQL OLE DB Provider and the SQL ODBC Driver into
one native dynamic link library (DLL) while also providing new
functionality that is separate and distinct from the Microsoft Data
Access Components (MDAC). SQL Native Client can be used to create new
applications or enhance existing applications that need to take advantage
of new SQL Server 2005 features such as Multiple Active Result Sets
(MARS), User-Defined Types (UDT), and XML data type support.

Note SQL Native Client is not supported with SQL Server versions
6.5 and earlier.

ADO.NET

ADO.NET is an evolutionary improvement over traditional ADO for creating
distributed, data sharing applications. It is a high-level application
programming interface that is targeted at loosely coupled, n-tier,
Internet-based applications that support disconnected access to data. It
is a core component of the Microsoft .NET Framework.

Figure 2. ADO.NET architecture

ADO.NET provides .NET-managed providers for connected access, and
DataSets that read and write in XML for disconnected management of
retrieved data and user interaction. The following data providers are
available for ADO.NET:

* Microsoft SQL .NET Data Provider: This provider allows .NET
applications to directly access a Microsoft SQL Server database.
* Microsoft OLE DB .NET Data Provider: This provider allows .NET
applications to access databases using their native OLE DB Providers.
* Microsoft ODBC .NET Data Provider: This provider allows .NET
applications to access databases by using their ODBC drivers.
* Microsoft Oracle .NET Data Provider: This provider allows .NET
applications to access an Oracle database.

The DataSet reads and writes XML and the XMLDataDocument integrates
relational and XML views.
Obsolete Data Access Technologies

Obsolete technologies are technologies that have not been enhanced or
updated in several product releases and that will be excluded from future
product releases. Do not use these technologies when you write new
applications. When you modify existing applications that are written
using these technologies, consider migrating those applications to
ADO.NET.

The following components are considered obsolete:

* DB-Library: This is a SQL Server-specific programming model that
includes C APIs. There have been no feature enhancements to the DB-
Library since SQL Server 6.5. Its final release was with SQL Server 2000
and it will not be ported to the 64-bit Windows operating system.
* Embedded SQL (E-SQL): This is a SQL Server-specific programming
model that enables Transact-SQL statements to be embedded in Visual C
code. No feature enhancements have been made to the E-SQL since SQL
Server 6.5. Its final release was with SQL Server 2000 and it will not be
ported to the 64-bit Windows operating system.
* Data Access Objects (DAO): DAO provides access to JET (Access)
databases. This API can be used from Microsoft Visual Basic®, Microsoft
Visual C++®, and scripting languages. It was included with Microsoft
Office 2000 and Office XP. DAO 3.6 is the final version of this
technology. It will not be available on the 64-bit Windows operating
system.
* Remote Data Objects (RDO): RDO was specifically designed to access
remote ODBC relational data sources, and made it easier to use ODBC
without complex application code. It was included with Microsoft Visual
Basic versions 4, 5, and 6. RDO version 2.0 was the final version of this
technology.

--
Lyle Fairfield

[David W. Fenton]

pi********@hotmail.com wrote in
news:11**********************@f14g2000cwb.googlegr oups.com:

Sorry, the great and powerful thought police of CDMA have spoken.
pay no attention to the man behind the curtain. If he really
doesn't want to answer your question, he can choose not to.
I'll ask you the same question I asked Steve:

Did you read my post? I did *not* tell the poster *not* to post in
the newsgroup. This is what I wrote in MessageID
<11**********************@f14g2000cwb.googlegroups .com>:

================================================== ======
Steve Jorgensen <no****@nospam.nospam> wrote in
news:5o********************************@4ax.com:
On Wed, 30 Nov 2005 05:47:14 GMT, "MP" <no****@Thanks.com> wrote:

I'm interested to learn how to use mdb files via ado/adox via vb6
Since I'm not using Access are those types of questions o.t. here?I see very few ado questions here. But there's a lot more traffichere than the ado groups.
:-)

If it has to do with MDBs or JET, I'd say it's close enough. Ask
away.

I wouldn't.

Using an MDB from VB is not Access, in any way, shape or form.

But there are likely people who've dealt with the same issues in
Access, so one would likely have a good chance of getting an
answer.

But it's important that the questions be asked in a way that makes
it clear that ACCESS is not involved in the question at all.
================================================== ======

I didn't say not to post. I said that one would likely get good
answers here on relevant topics if the questions were well-framed,
and clearly maintained the distinction between Jet and Access.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Larry Linson]

Lyle,

That does appear to be a true copy of MDAC information. And your point
is...?

"Don't believe anything you hear and only half of what you read," they say.

Larry

[jimfortune]

Larry Linson wrote:

Lyle,

That does appear to be a true copy of MDAC information. And your point
is...?

"Don't believe anything you hear and only half of what you read," they say.

Larry

Lyle can explain his point but the point I got out of it was that MS
only makes a GREAT version of Access when the machine bit sizes double
:-). It's good to know that SQLOLEDB will receive a lot of attention
(boolSurprise = False).

James A. Fortune

[Larry Linson]

<ji********@compumarc.com> wrote

Lyle can explain his point but the point I got out of it was that MS
only makes a GREAT version of Access when the machine bit sizes double
:-). It's good to know that SQLOLEDB will receive a lot of attention
(boolSurprise = False).

I 'spect I've said enough on the subject.

Larry