Re: Access 2010 with Sharepoint 2010

Albert, I think you missed one of my posts. You posted the link to
the list of things that are not supported with Sharepoint for A2007,
and I asked if you could take a stab at saying how that list stacks
up under the forthcoming A2010. Here's the full post, and it would
be great if you could address any of it that you're able:

"Albert D. Kallal" <PleaseNOOOsPAMmkallal@xxxxxxx> wrote in
news:AX1Jm.4744$ZF3.1279@xxxxxxxxxxxx:

A
2007 list of limitations is outlined here:

http://office.microsoft.com/en-us/access/HA101314681033.aspx?pid=CH
101741461033

However with access 2010, a big portion of the above list
"limitations" is changed in a big way.

Can you address that list, Albert, item by item, or at least the
ones about which you have something to say?

=====================================================================
1. COM object data type: SharePoint sites do not support the COM
Object data type. Result: Field is not moved.

DWF: can this be migrated to an Attachment field?

=====================================================================
2. Binary data type: SharePoint sites do not support the Binary
data type. Result: Field is not moved.

DWF: this seems like not much of an issue. I've never encountered
the binary data type in Access except with MakeTable queries on
columns with all Null values (Jet or Access seems to abdicate
responsibility for guessing the data type and uses Binary(512), or,
at least, it did in A2000 -- haven't checked it since then as I just
don't do MakeTables very often, but I encountered it in somebody
else's work). For binary fields used to store BLOBs, can those be
moved to attachments if they are saved out to the file system? I'd
think not, but given that I don't use this field type, there may be
lots going on that I'm not aware of.

=====================================================================
3. Date: SharePoint sites do not support dates prior to 1900.
Result: Data with dates prior to 1900 is not moved.

DWF: this seems a major lack to me. What's the workaround? Has it
been addressed?

=====================================================================
4. New line characters in text fields: SharePoint sites do not
support new line characters in a Single Line of Text field. Result:
Field is converted to a Multiple Lines of Text field or Memo field.

DWF: if you convert to the multi-value memo fields in your ACCDB, is
the order of entry of the paragraphs maintained? What happens when
you edit a paragraph in the middle after the paragraphs have been
added? Does it stay in the same location in the order of paragraphs?
If not, what is the solution? Is there any?

=====================================================================
5. Decimal data type: SharePoint sites do not support the Decimal
data type. Result: The Number field or Double Integer field is used
instead.

DWF: Access doesn't really support decimal data type very well
(e.g., http://allenbrowne.com/bug-08.html and
http://bytes.com/topic/access/answers/446518-decimal-data-type-jet-dd
l-sql), so I haven't used it. It would seem to be useful, but I get
by with Double, Single and Currency in my apps, all of which I
assume are supported in Sharepoint, yes?

=====================================================================
6. Replication ID data type: SharePoint sites do not support the
Replication ID data type. Result: A Single Line of Text data type is
used instead, depending on the type of data.

DWF: This one confuses me. What does Sharepoint use for it's PK
field? I would have assumed a GUID. In an app using GUIDs for PK, it
would seem something better ought to be done with this. Is this one
of the things addressed in supporting RI? Seems like you couldn't
very well say you support RI if you don't support the use of GUIDs
for PK/FK values.

=====================================================================
7. Referential integrity: SharePoint sites do not support
referential integrity. Result: Referential integrity is not enforced
in the new list.

DWF: in regard to the previous comment, are there limitations on
this besides no support for multi-column keys, as you've already
said? Any data type limitations?

=====================================================================
8. Default values that are not supported in a SharePoint list:
SharePoint sites accept default values that are static, such as text
or a number, as well as standard dates. Default values from Access
that are dynamic are not migrated. Result: Certain default value
properties are not moved.

DWF: is this one changed? It's not RI-related, but seems like a
pretty easy one to address, at least by adding support for the most
obvious defaults drawn from functions, such as Date() and Now().

=====================================================================
9. Data validation on a field or table: No data validation rules
are moved to SharePoint sites. Result: Any data validation on a
field or table is not moved or enforced.

DWF: Is this one impacted by the RI implementation? I wouldn't
expect it to be, but I could see certain table-level validation
rules fitting into an RI implementation fairly easily. This one
doesn't bother me so much, as I don't use very many of them and
could easily live without them (most of my validation is via RI or
enforced with front end controls that restrict entry; I know that's
not complete, but I find the Access validation messages that bubble
up through the UI to be annoying and too difficult to work around).

=====================================================================
10. Unique index fields: SharePoint sites use one unique index
field for its ID column in a list. Result: Other unique index fields
or sets of fields are not moved.

DWF: surely this one is altered by the implementation of RI, no? Of
course, if there's still no multi-column indexing, this would be
pretty problematic for a lot of cases.

=====================================================================
11. Relationships with cascading deletes or updates: SharePoint
sites do not support cascading deletes to related records. Result:
Deletes are not cascaded to related records, and updates are not
cascaded to related fields.

DWF: Obviously, this one is gone based on RI. Are there any notable
differences between Jet/ACE cascade other than lack of support for
cascade update (which is useless in my opinion since any field
that's going to be updated is not a proper candidate for a PK)?

=====================================================================
12. Relationships that enforce referential integrity: SharePoint
sites do not support referential integrity. Result: Referential
integrity is not enforced in the relationships between data in the
lists.

DWF: It's not clear to me from your comments that real RI is offered
in the new version. You've definitely said CASCADE DELETE is offered
as well as CASCADE DELETE RESTRICT (which I'd assume is the same as
enforcing RI with CASCADE DELETE set to OFF), but are column values
restricted to those drawn from the PK of a different table/list?

=====================================================================
13. Fields that enumerate automatically (other than the ID
field): SharePoint sites support only automatic numbering for the
field used for the ID column in a list. Result: Automatic numbering
is not applied to columns other than the ID column.

DWF: This is one that is very unclear to me. I understand that
Sharepoint in the version compatible with A2007 put all your lists
in a single table and then presented individual lists to you from
that table hiding the actual underlying implementation (or, at
least, that's my understanding), so I'd presume this means that only
one of your lists could have Sharepoint's equivalent of the Jet/ACE
Autonumber field. With a form of RI implemented, has this been
altered?

=====================================================================
14. Relationships in which lookups cannot be created: Some
relationships are not supported in SharePoint sites, such as when
the primary key is not related to the ID column or is not an
integer. Result: The relationship is not moved.

DWF: This one confuses me a lot. I thought *no* relationships were
moved?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.

Relevant Pages

  • Re: Access 2010 article
    ... COM object data type: SharePoint sites do not support the COM ... Sharepoint in the version compatible with A2007 put all your lists ...
    (comp.databases.ms-access)
  • Re: Access 2010 with Sharepoint 2010
    ... COM object data type: SharePoint sites do not support the COM ...
    (comp.databases.ms-access)
  • SourceForge.net Sitewide update June 23rd, 2004 (fwd)
    ... Puzzle ITC provides software development services based on Open Source ... support of SourceForge.net. ... recent rolled out several other new features, ... lists. ...
    (comp.os.linux.announce)
  • Re: A convert to Apple says thanks
    ... questions in the thread "A convert to Apple needs friendly ... Clearly, Mac ... CCMP support seems to be quite a new thing and thus still quite ... > The 802.1X config panel lists these authentication mechanisms ...
    (uk.comp.sys.mac)
  • Re: Anthonys drive issues.Re: ssh password delay
    ... the equivalent of Windows 2003 in terms of release ... drivers for the Mac, latest Windows, and Linux support. ... > FreeBSD. ... I got help from the lists, ...
    (freebsd-questions)