How to determine if an ADO Recordset column is required

I'm having a bit of a brain cramp and need a shove in the right direction.

One thing that really bogs me down is having to go back and forth trying to
catch every ASP page SNAFU when the database schema gets a subtle change
like making an optional column (nulls allowed) a required column (not null).
I am attempting to write a generalized pre-validation to compare the
incoming data with the schema definition.

(If you happen to know of such an example already written up, it would be
/*really*/ nice if you could share!)

What property of what object will tell me if a column in an ADO Recordset is
required to have a not null value?

TIA

Re: How to determine if an ADO Recordset column is required

MyndPhlyp wrote:
> I'm having a bit of a brain cramp and need a shove in the right
> direction.
>
> One thing that really bogs me down is having to go back and forth
> trying to catch every ASP page SNAFU when the database schema gets a
> subtle change like making an optional column (nulls allowed) a
> required column (not null). I am attempting to write a generalized
> pre-validation to compare the incoming data with the schema
> definition.
>
> (If you happen to know of such an example already written up, it
> would be /*really*/ nice if you could share!)

I've never seen one and have never seen the need to do so. Mainly because i
don't use recordsets for data maintenance in ASP.
>
> What property of what object will tell me if a column in an ADO
> Recordset is required to have a not null value?
>

There is no property that applies to all providers, because not all
providers supply this information. You will need to tell us your backend
database for us to be able to tell you if such a property exists.

Go to msdn.microsoft.com/library and look up the documentation for ADOX.

Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

Re: How to determine if an ADO Recordset column is required

MyndPhlyp wrote:
> I'm having a bit of a brain cramp and need a shove in the right direction.
>
> One thing that really bogs me down is having to go back and forth trying to
> catch every ASP page SNAFU when the database schema gets a subtle change
> like making an optional column (nulls allowed) a required column (not null).
> I am attempting to write a generalized pre-validation to compare the
> incoming data with the schema definition.
>
> (If you happen to know of such an example already written up, it would be
> /*really*/ nice if you could share!)
>
> What property of what object will tell me if a column in an ADO Recordset is
> required to have a not null value?
>
> TIA
>
>
see
http://groups-beta.google.com/group/microsoft.public.inetser ver.asp.general/browse_thread/thread/ad92e7fc6e9e9009/0e0721 5c7298ac63?q=%22adFldIsNullable%22+required+field&_done=%2Fg roups%3Fhl%3Den%26safe%3Dimages%26num%3D10%26q%3D%22adFldIsN ullable%22+required+field%26qt_s%3DSearch+Groups%26&_doneTit le=Back+to+Search&&d#0e07215c7298ac63
and
http://groups-beta.google.com/group/microsoft.public.data.ad o/browse_thread/thread/ef2363c473b6741e/806e27f10f5e58ab?q=% 22adFldIsNullable%22+required+field&_done=%2Fgroups%3Fhl%3De n%26safe%3Dimages%26num%3D10%26q%3D%22adFldIsNullable%22+req uired+field%26qt_s%3DSearch+Groups%26&_doneTitle=Back+to+Sea rch&&d#806e27f10f5e58ab

Re: How to determine if an ADO Recordset column is required

"Michael D. Kersey" wrote in message
news:eScodTw4EHA.2540@TK2MSFTNGP09.phx.gbl...
>
<...snip...>

Thanx. I can see this is going to be a bit of a chore. Field.Attributes is
the key but adFldIsNullable may or may not be available depending on the
connection method, the data source vendor, the versions, the direction of
the winds, the alignment of the planets and the whims of the gods. Piece of
cake.

Re: How to determine if an ADO Recordset column is required

"Bob Barrows [MVP]" wrote in message
news:eI5DwDv4EHA.2600@TK2MSFTNGP09.phx.gbl...
>
> I've never seen one and have never seen the need to do so. Mainly because
i
> don't use recordsets for data maintenance in ASP.

What do you use for data maintenance in ASP?

As for the rest, I'm initially going after an Access database via its native
ODBC driver. Yes, I am aware there are limitations working with Access.
Eventually I plan on moving it over to SQL Server or some other RDBMS once I
settle a few issues. It's just a bit more convenient (oxymoron) to flail
away with this.

Re: How to determine if an ADO Recordset column is required

MyndPhlyp wrote:
> "Bob Barrows [MVP]" wrote in message
> news:eI5DwDv4EHA.2600@TK2MSFTNGP09.phx.gbl...
>>
>> I've never seen one and have never seen the need to do so. Mainly
>> because i don't use recordsets for data maintenance in ASP.
>
> What do you use for data maintenance in ASP?

SQL: INSERT, UPDATE and DELETE statements, via stored procedures

>
> As for the rest, I'm initially going after an Access database via its
> native ODBC driver.

You should be using the native OLEDB provider. See this:
http://www.aspfaq.com/show.asp?id=2126

Since you are using Access, think "saved parameter queries" instead of
stored procedures. See these links for pointers:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&c2coff=1& selm=eHYxOyvaDHA.4020%40tk2msftngp13.phx.gbl

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&c2coff=1& selm=ukS%246S%247CHA.2464%40TK2MSFTNGP11.phx.gbl

http://www.google.com/groups?selm=eETTdnvFDHA.1660%40TK2MSFT NGP10.phx.gbl&oe=UTF-8&output=gplain

http://www.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&sel m=e6lLVvOcDHA.1204%40TK2MSFTNGP12.phx.gbl


Bob Barrows

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

Re: How to determine if an ADO Recordset column is required

MyndPhlyp wrote:

> "Michael D. Kersey" wrote in message
> news:eScodTw4EHA.2540@TK2MSFTNGP09.phx.gbl...
> <...snip...>
>
> Thanx. I can see this is going to be a bit of a chore. Field.Attributes is
> the key but adFldIsNullable may or may not be available depending on the
> connection method, the data source vendor, the versions, the direction of
> the winds, the alignment of the planets and the whims of the gods. Piece of
> cake.
>
It's actually quite straightforward. Microsoft Access does this easily;
it should be as easy with SQL Server. But note that the URLs I gave
included a warning that ODBC may not work and that OLEDB may be
necessary. I mention this because in another post you indicate that you
intend to use ODBC initially.

Re: How to determine if an ADO Recordset column is required

"Michael D. Kersey" wrote in message
news:eN1NO2z4EHA.824@TK2MSFTNGP11.phx.gbl...
> MyndPhlyp wrote:
>
> > "Michael D. Kersey" wrote in message
> > news:eScodTw4EHA.2540@TK2MSFTNGP09.phx.gbl...
> > <...snip...>
> >
> > Thanx. I can see this is going to be a bit of a chore. Field.Attributes
is
> > the key but adFldIsNullable may or may not be available depending on the
> > connection method, the data source vendor, the versions, the direction
of
> > the winds, the alignment of the planets and the whims of the gods. Piece
of
> > cake.
> >
> It's actually quite straightforward. Microsoft Access does this easily;
> it should be as easy with SQL Server. But note that the URLs I gave
> included a warning that ODBC may not work and that OLEDB may be
> necessary. I mention this because in another post you indicate that you
> intend to use ODBC initially.

I believe I'm using the native driver for Access. {Microsoft Access Driver
(*.mdb)};DBQ=URL=database.mdb

I do find it rather amusing all the difficulties involved in building
something to fit multiple database vendors. Always catering to the least
common denominator. For something that is supposed to provide a generic
interface (ODBC), it tends to cause many sleepless nights. Intersolv drivers
seem to hold up very nicely. Too bad the database manufacturers cannot seem
to write a driver properly.

Re: How to determine if an ADO Recordset column is required

MyndPhlyp wrote:
>
> I believe I'm using the native driver for Access. {Microsoft Access
> Driver (*.mdb)};DBQ=URL=database.mdb
>
You are using the native _ODBC_ driver. You should be using the native Jet
OLE DB provider:

"Provider=Microsoft.Jet.OLEDB.4.0;: & _
"data source=" & server.mappath("database.mdb")

Bob Barrows
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Re: How to determine if an ADO Recordset column is required

"Bob Barrows [MVP]" wrote in message
news:eGC%23q354EHA.3472@TK2MSFTNGP09.phx.gbl...
> MyndPhlyp wrote:
> >
> > I believe I'm using the native driver for Access. {Microsoft Access
> > Driver (*.mdb)};DBQ=URL=database.mdb
> >
> You are using the native _ODBC_ driver. You should be using the native Jet
> OLE DB provider:
>
> "Provider=Microsoft.Jet.OLEDB.4.0;: & _
> "data source=" & server.mappath("database.mdb")


D'oh!

Re: How to determine if an ADO Recordset column is required

"Bob Barrows [MVP]" wrote in message
news:eGC%23q354EHA.3472@TK2MSFTNGP09.phx.gbl...


Okay, I'm missing something here. Jet 4.0 is installed. I even went so far
as to redownload and reinstall SP8. I double-checked the connection string
and, according to all the pictures, it looks fine. When I try to do a simple
Open on the connection, it dumps back:

Microsoft JET Database Engine (0x80004005)
Could not find installable ISAM.

Plowing through the Registry there are ISAM definitions for dBase, Excel,
Exchange, HTML, Jet, Lotus, Outlook, Paradox, and Text. Nothing for an
Access MDB.

The portion of the Registry I'm looking at is
HKLM/Software/Microsoft/Jet/4.0/ISAM Formats

The stuff under the Engines is a similar list.

Re: How to determine if an ADO Recordset column is required

MyndPhlyp wrote:
> "Bob Barrows [MVP]" wrote in message
> news:eGC%23q354EHA.3472@TK2MSFTNGP09.phx.gbl...
>
>
> Okay, I'm missing something here. Jet 4.0 is installed. I even went
> so far as to redownload and reinstall SP8. I double-checked the
> connection string and, according to all the pictures, it looks fine.
> When I try to do a simple Open on the connection, it dumps back:
>
> Microsoft JET Database Engine (0x80004005)
> Could not find installable ISAM.
>
> Plowing through the Registry there are ISAM definitions for dBase,
> Excel, Exchange, HTML, Jet, Lotus, Outlook, Paradox, and Text.
> Nothing for an Access MDB.
>
> The portion of the Registry I'm looking at is
> HKLM/Software/Microsoft/Jet/4.0/ISAM Formats
>
> The stuff under the Engines is a similar list.
Your error is covered here:
http://www.aspfaq.com/show.asp?id=2009

Specifically, see the link to here:
http://www.aspfaq.com/show.asp?id=2259

Bob Barrows
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Re: How to determine if an ADO Recordset column is required

"Bob Barrows [MVP]" wrote in message
news:eZmjO064EHA.3376@TK2MSFTNGP12.phx.gbl...
> MyndPhlyp wrote:
> > "Bob Barrows [MVP]" wrote in message
> > news:eGC%23q354EHA.3472@TK2MSFTNGP09.phx.gbl...
> >
> > Microsoft JET Database Engine (0x80004005)
> > Could not find installable ISAM.
> >
>
> Your error is covered here:
> http://www.aspfaq.com/show.asp?id=2009
>
> Specifically, see the link to here:
> http://www.aspfaq.com/show.asp?id=2259

Saw both of them (and several others while Googleing). Downloaded and
re-reinstalled MDAC 2.8, already re-reinstalled Jet 4.0 SP8, checked the
Registry entries in HKLM/Software/Microsoft/Jet/4.0/Engines, tried
re-registering each of the DLLs just for grins, did a Repair on Office 2K
Pro, did both Windows and Office updates - all sorts of things chasing this
one symptom. Nothing seems to be clearing this up.

Even though the GLOBAL.ASA hashes out the connection string correctly using
Server.MapPath, I hand wrote the connection string including the UID and PWD
parameters. The snippet of VBScript code is:

Dim conStr
conStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & _
"c:\inetpub\wwwroot\fpdb\prod.mdb;UID=admin;PWD=secret"
Dim conProd
Set conProd = Server.CreateObject("ADODB.Connection")
conProd.Open conStr,"",""

The Access MDB is a fresh creation using Access 2000; nothing fancy yet,
just a few tables. The server is Win2K. I must be missing something very
basic.

Re: How to determine if an ADO Recordset column is required

MyndPhlyp wrote:
.. The snippet of VBScript code is:
>
> Dim conStr
> conStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & _
> "c:\inetpub\wwwroot\fpdb\prod.mdb;UID=admin;PWD=secret"

This is not the syntax for the connection string that I showed you.

Is your database secured with workgroup security? If not, leave out the uid
and pwd attributes. All you need are the Provider and Data Source.

If it is secured with workgroup security, then see
www.able-consulting.com/ado_conn.htm for the proper syntax to use when
opening a workgroup-secured database. (it involves specifying the system
database)

Bob Barrows
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Re: How to determine if an ADO Recordset column is required

"Bob Barrows [MVP]" wrote in message
news:%23ZD99f74EHA.1976@TK2MSFTNGP09.phx.gbl...
> MyndPhlyp wrote:
> . The snippet of VBScript code is:
> >
> > Dim conStr
> > conStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & _
> > "c:\inetpub\wwwroot\fpdb\prod.mdb;UID=admin;PWD=secret"
>
> This is not the syntax for the connection string that I showed you.
>
> Is your database secured with workgroup security? If not, leave out the
uid
> and pwd attributes. All you need are the Provider and Data Source.
>
> If it is secured with workgroup security, then see
> www.able-consulting.com/ado_conn.htm for the proper syntax to use when
> opening a workgroup-secured database. (it involves specifying the system
> database)

Using standard security, not workgroup security.

Followed the example:

oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=c:\inetpub\wwwroot\fpdb\prod.mdb;" & _
"User Id=admin;" & _
"Password=secret"

(Just a minor tweak - User Id instead of UID, Passwrod instead of PWD.)
Managed to generate a different error.

Microsoft JET Database Engine (0x80040E4D)
Cannot start your application. The workgroup information file is missing or
opened exclusively by another user.

Now I'm off to hunt that one down. Fun, fun, fun.

Re: How to determine if an ADO Recordset column is required

Curiouser and curiouser. If I eliminate the password on the Access database,
life is good.

I did stumble across one article stating that "Password" should be "Database
Password" but that just took me back to the previous symptom.

Re: How to determine if an ADO Recordset column is required

MyndPhlyp wrote:
>
> Using standard security, not workgroup security.
>
> Followed the example:
>
> oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
> "Data Source=c:\inetpub\wwwroot\fpdb\prod.mdb;" & _
> "User Id=admin;" & _
> "Password=secret"
>

You aren't following the example correctly. Is your database password
secured? If not, then all you need to supply is Provider and Data Source. Do
not supply anything else! No username. No password. (I know the example has
"User Id=admin;" & _
"Password="
Ignore that part. It is not needed.


If your database is password-secured, then you need to use this example:
oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=c:\somepath\mydb.mdb;" & _
"Jet OLEDB:Database Password=MyDbPassword"

Ignore the part about supplying a user name and password. I need to write
Carl and tell him he goofed there.

The ONLY time you supply a user name and password is if you have used
workgroup security to secure your database. If you supply a user name and
password, Jet assumes that you have workgroup security and looks for the
*.mdw file which contains the security information.

Bob Barrows

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Re: How to determine if an ADO Recordset column is required

"Bob Barrows [MVP]" wrote in message
news:OiN$qn84EHA.1452@TK2MSFTNGP11.phx.gbl...
> MyndPhlyp wrote:
> >
> > Using standard security, not workgroup security.
> >
> > Followed the example:
> >
> > oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
> > "Data Source=c:\inetpub\wwwroot\fpdb\prod.mdb;" & _
> > "User Id=admin;" & _
> > "Password=secret"
> >
>
> You aren't following the example correctly. Is your database password
> secured? If not, then all you need to supply is Provider and Data Source.
Do
> not supply anything else! No username. No password. (I know the example
has
> "User Id=admin;" & _
> "Password="
> Ignore that part. It is not needed.
>
>
> If your database is password-secured, then you need to use this example:
> oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
> "Data Source=c:\somepath\mydb.mdb;" & _
> "Jet OLEDB:Database Password=MyDbPassword"
>
> Ignore the part about supplying a user name and password. I need to write
> Carl and tell him he goofed there.
>
> The ONLY time you supply a user name and password is if you have used
> workgroup security to secure your database. If you supply a user name and
> password, Jet assumes that you have workgroup security and looks for the
> *.mdw file which contains the security information.

In the 11th hour (literally) I stumbled across "Jet OLEDB:Database Password"
and gave it a try. It works - with or without the "User Id" parameter.
Dutifully returning to post the results, I found your reply. Thanx.

The down side to all this is that using the native Access ODBC driver
[Microsoft Access Driver (*.mdb)] yields the same results as using the
native Jet OLE DB driver [Microsoft.Jet.OLEDB.4.0]. The up side, I feel
better about finally getting the Jet connection to work.

Now I'm back to the original question.

I tried displaying rs.Fields("somefield").Attributes, but all the values
being returned are <= 2 and the adFldIsNullable constant is defined as 32
(Hex 20) in my ADOVBS include. What am I missing here besides clues,
education and a life?

Re: How to determine if an ADO Recordset column is required

Perhaps the final chapter in this little episode.

Using an ADOX Catalog, pointing to the same ADODB Connection using OLEDB
(Jet), I was finally able to locate a Properties that is almost entirely
reliable. ("Nullable") The only reason I say "almost" is because I have an
AutoNumber column as the Primary Key that shows up as Nullable. Since that
column is automatically populated by Access, it doesn't really matter.

More experimentation - since Jet is pretty much a deadend in terms of life
cycle, I'd really like to find a way to do this with DSN-less ODBC. Then
there's the fun of trying it with different database vendors. If the
resulting lump on my forehead (from pounding my head on the keyboard)
becomes too large I may just drop this idea and get back to my rendition of
productivity.

Thanx for the assist.

Re: How to determine if an ADO Recordset column is required

MyndPhlyp wrote:
> Perhaps the final chapter in this little episode.
>
> Using an ADOX Catalog, pointing to the same ADODB Connection using
> OLEDB (Jet), I was finally able to locate a Properties that is almost
> entirely reliable. ("Nullable") The only reason I say "almost" is
> because I have an AutoNumber column as the Primary Key that shows up
> as Nullable. Since that column is automatically populated by Access,
> it doesn't really matter.
>
> More experimentation - since Jet is pretty much a deadend in terms of
> life cycle, I'd really like to find a way to do this with DSN-less
> ODBC.

I do not understand your obsession about using the obsolete ODBC provider.
It will not provide the functionality, robustness or performance that you
will get from using the native Jet OLE DB provider. Look, in order to use
ODBC, your application has to go through two software layers: the OLE DB
provider for ODBC interface, and the ODBC API. With the native Jet provider,
OLE DB talks directly to the Jet database: less software to load into memory
equals better performance and less chance for breakdowns to occur. Plus,
since the OLE DB provider for ODBC has been deprecated for several versions
of MDAC, new functionality has been added to the native providers that has
not been added to the ODBC provider.

Bob Barrows

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

Re: How to determine if an ADO Recordset column is required

MyndPhlyp wrote:
> Perhaps the final chapter in this little episode.
>
> Using an ADOX Catalog, pointing to the same ADODB Connection using
> OLEDB (Jet), I was finally able to locate a Properties that is almost
> entirely reliable. ("Nullable") The only reason I say "almost" is
> because I have an AutoNumber column as the Primary Key that shows up
> as Nullable. Since that column is automatically populated by Access,
> it doesn't really matter.
>
With Access Text fields, you also have to worry about another property:
Allow Zero-Length Strings. You can get at this property using ADOX - see the
documentation at msdn.microsoft.com/library.


Most experienced developers avoid this problem by never creating nullable
fields, always providing a default value if none is provided by the user.
Most of us also avoid using recordsets, given their inefficiencies, to
maintain data in ASP. Recordsets are fine in desktop applications, but will
severely limit the scalability of server-based applications. Do yourself a
favor and read up on using saved parameter queries to do you data
maintenance. It will prepare you for the world of SQL Server. Here are some
liinks:


http://www.google.com/groups?selm=eETTdnvFDHA.1660%40TK2MSFT NGP10.phx.gbl&oe=UTF-8&output=gplain

http://www.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&sel m=e6lLVvOcDHA.1204%40TK2MSFTNGP12.phx.gbl


Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

Re: How to determine if an ADO Recordset column is required

"Bob Barrows [MVP]" wrote in message
news:%23hpmHDD5EHA.1392@tk2msftngp13.phx.gbl...
>
> I do not understand your obsession about using the obsolete ODBC provider.

Don't take it personally.

Even I am amazed (amused) by my various obsessions. With regards to anything
computer-related, when faced with obstacles, my tendency is to continue
working at the problem until I have either found a way to overcome it to my
satisfaction or somehow manage to convince myself I just can't get what I
desire. The latter part of that is really tough. There have been many a
sleepless night (as witnessed by the time stamps) due to unanswered
questions running through my head.

I know I'm fighting a battle I probably cannot win (there's that obsession
thing again, still not letting me give in easily). Having worked with
various databases, various programming languages, various operating systems
and various hardware, all open or proprietary, over the last 25 years has
taught me much. Taking the easy way out is one lesson I've yet to learn.
This tenacious nature though has been an asset.

I'm /*almost*/ convinced to abandon ODBC in favor of OLE DB. I put together
a couple of ASP pages to query up Properties and Attributes of the various
columns/fields using ADODB and ADOX objects, one using ODBC and the other
using OLE DB. There is a very significant difference. (Like I had to tell
you that.) Right now the OLE DB and ADOX combination is in the lead.

Next up on the list is to dig into OpenSchema. The documentation is a bit
more cryptic and the methods are not very desirable. Most definitely it will
be difficult to write clean self-describing code. Once I get past this one
I'll be able to satisfy my curiosity and get on with things ... maybe. (If I
uncover yet another possible path I'll be chasing in that direction too.)

My thanks again for your patience, assistance and provided links (they've
been bookmarked for future reference).

Re: How to determine if an ADO Recordset column is required

Bob:

After many hours paralleled with many cups of strong coffee I believe I have
quelled most of the voices in my head. You will probably not be surprised by
my findings but I am compelled to share nonetheless.

Under ODBC

Going after ADODB Recordset.Field.Properties yields all possible property
keys whether or not there is a value associated with that property.

The ADODB Recordset.Field.Attributes does yield values but I am unsure what
they actually represent. (read: There may be more sleep lost.)
"Recordset.Field.Attributes And adFldIsNullable" does not generate a
reliable result. The range of values is 16-116 (decimal).

Going after ADOX Catalog.Tables.Columns.Attributes yields a value completely
different from accessing via ADODB Recordset. The range of values is 1-3.

I was unable to retrieve any values from ADOX
Catalog.Tables.Columns.Properties.

OpenSchema showed conflicting results with the OLE DB connection method. The
returns from adSchemaColumns showed TABLE_CATALOG, the COLUMN_FLAGS
contradict, and an ORDINAL property is present. There is, I think, one other
property added to the list but it is an empty value.

The OpenSchema IS_NULLABLE property is very unreliable. It showed both
required and non-required columns to be nullable, the autonumbered primary
key and a boolean column to be not nullable - far from the schema
definition.

Under OLE DB

The ADODB Recordset.Field.Properties list is shorter and only those
properties with values are returned.

The ADODB Recordset.Field.Attributes yields values different from the ODBC
connection method and I'm still at a loss what the value represents. As with
ADODB, testing for adFldIsNullable is completely out of the question. The
range of values is 86-102 (decimal).

The ADOX Catalog.Tables.Columns.Attributes differ from the ODBC connection
method. The range of values is 0-2. It is not a matter of zero-relative
versus one-relative.

ADOX Catalog.Tables.Columns.Properties does yield a list of properties and
values including a "Nullable" property that is unreliable.

The values returned for the property IS_NULLABLE from OpenSchema for
adSchemaColums is by far the most promising. On the one table that I
initially targeted it managed to identify correctly the required and
non-required columns

Hypothisis

OpenSchema(adSchemaColumns, Array(Empty,Empty,table,column)) using the OLE
DB connection method checking the IS_NULLABLE property boolean value is the
route to go for determining if a field is required or not. This was tested
using an Access 2000 MDB with standard security via IIS 5 on Win2K and all
results will probably be invalidated when I attempt this with other
database, IIS and OS OS environments.

Thanks again.