[AccessD] This on SharePoint

Eric Barro ebarro at verizon.net
Tue Jun 5 13:46:32 CDT 2007


With SP efficiency or productivity is measured in the following ways:

1. How fast the end user can access his data given the fact that it may be
in Word, Excel, Access, PDF or any other format.
2. How quickly the end user can collaborate with other users given the fact
that each will have access to their information via SP.
3. How easy it is for the user to upload his data files to SP without
knowing about FTP.
4. How easy it is for users to synchronize their copy of an Excel
spreadsheet stored in SP.
5. How easy it is for users to quickly view the team's event calendar to
determine timelines and resources.
6. How easy it is for users to load their browser, navigate to the SP URL,
login to the site and have access to the information that team members have
access to as well.
7. How easy it is for users to be notified of any changes (adds/updates) to
site content whenever it happens in real time.

8. How easy it is for administrators or team managers to create a team site
for collaboration, discussion, document management with zero programming by
using features right out of the box.
9. How easy it is for administrators or team managers to grant site access.
10. How easy it is for administrators to provide for all these servers
without having to wait on the programming team to design and develop all
that functionality.

Those are just a few...

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, June 05, 2007 11:25 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] This on SharePoint

>My first question is: Why would you want to?

Want to what?

>SP is efficient and we use it extensively.

What is the measure of efficiency?  Storage requirements?  Speed of access?
Speed of development?  Organization of information?  Relating information?

>It doesn't make sense...

What doesn't make sense?

I am just poking and prodding to discover what it is and why it exists.

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Hewson
Sent: Tuesday, June 05, 2007 2:16 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] This on SharePoint

My first question is: Why would you want to?
SP is efficient and we use it extensively.
We manage several very large IDIQ contracts with as many a 60 plus
subcontractors, each with their own site, each with their own permissions.
In one SP instance we have 64 subcontractors, 15 active projects and have
probably managed at least 50 proposals with a total of about 300 users.
We use Access on some web-parts to hold data where lists are not
appropriate.
We create some of our own web-parts using C#.
It doesn't make sense...

Jim
jhewson at karta.com
 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: Tuesday, June 05, 2007 12:58 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] This on Sharepoint

It's more a condemnation of SharePoint than it is of Access, John.

Charlotte Foust 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, June 05, 2007 10:52 AM
To: 'Access Developers discussion and problem solving'
Subject: [AccessD] This on Sharepoint

I just found this on a blog re Access 2007.  Since I don't use it, I can't
comment except to say, if it is true... OH MY GOD!

************************************************************

 Wednesday, October 11, 2006 2:13 AM by Mike

Do you know how data will be stored in SharePoint (SP) if you use SP as an
Access data store?  

In SP there is only ONE table that your data will be stored in.  That's
right, if your Access program has 5 tables (or a hundred tables) stored in
SharePoint, then data from the 5 (or 100) tables is intermingled into ONE
table.  The data table in SP is called UserData.

UserData is predefined by M$ to have 201 columns: 64 nvarchar(255), 16 int,
32 float, 16 datatime, 16 bit, 1 guid, 32 ntext, and 8 sql_variant (plus
16 non-user SP internal use columns).

So if you define a table in Access that has one integer column, and one
varchar(10) column and store it in SP, the table really has 201 columns (but
in this case only two columns will be used for your data).

There a few house keeping tables that SP uses, one is called Lists.
Lists is where your column names are stored.  So there is a map between your
column names and the predefined SP columns names of UserData.
Every time your data is read the map also needs to be read so that SP can
send the data to Access with the correct column names.  

The real columns names of UserData are (you guessed it): nvarchar1,
nvarchar2 - nvarcahr64, int1 - int16, float1- float32, datatime1 -
datatime16, bit1 - bit16, guid1, ntext1 - ntext32, sql_variant1 -
sql_variant8.

The rows of your table will be intermixed with rows from all other tables
and all SP "lists".  I'm not making this up!

Wow, all I can say is WOW WHAT A CLUGE!  It is boggling to even try to think
of the performance and interaction problems that can arise from such an
outright wacky scheme.

If you want to use SP with Access, there should be a big bold warning:

WARNING, STORING ACCESS DATA IN SHAREPOINT WACKY, IF YOU REALLY WANT TO DO
THIS, FIRST GO TO THE PHYSIATRIST TO CONFIRM THAT YOU ARE CRAZY.
THEN IF YOU ARE CERTIFIED CRAZY, ITS OK, YOU CAN MAKE IT WORK, JUST BE SURE
THAT YOU DON'T STORE MORE THAN A FEW ROWS OF SIMPLE DATA AND FOR BEST
PERFORMANCE DON'T ALLOW THE SHAREPOINT SERVER TO BE USED FOR ANYTHING OTHER
THAN YOUR JUMBLED UP PSEUDO TABLES.

Note, if you have virtual arrays of octal-hyper 100Ghz processors with 100Gs
of memory (like the M$ Access team) you may find that storing Access data in
the SharePoint pseudo tables may actually work during testing.  Use real
data on real systems at your own risk.

Using SharePoint for Access data storage will be as useful as Microsoft Bob.

************************************************************

Does anyone out there know anything about this?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.9/832 - Release Date: 6/4/2007 6:43
PM
 




More information about the AccessD mailing list