By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,321 Members | 1,875 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,321 IT Pros & Developers. It's quick & easy.

SharePoint: What Is It?

P: n/a
Got a sample of MS's "Advisor Guide To Microsoft Access" in the mail today -
accompanied by a sample "Advisor Guide To Microsoft SharePoint".

I skimmed both, but the SharePoint explanation is too abstract - it's going
right over my head.

Can somebody explain, in simple/concrete terms what MS SharePoint is?
--
PeteCresswell
Mar 22 '06 #1
Share this Question
Share on Google+
15 Replies


P: n/a
"(PeteCresswell)" <x@y.Invalid> wrote in
news:1t********************************@4ax.com:
Got a sample of MS's "Advisor Guide To Microsoft Access" in the
mail today - accompanied by a sample "Advisor Guide To Microsoft
SharePoint".

I skimmed both, but the SharePoint explanation is too abstract -
it's going right over my head.

Can somebody explain, in simple/concrete terms what MS SharePoint
is?


I'm pretty confused about it myself, but it's a server whose purpose
is data sharing/collaboration in an enterprise.

My understanding is that in Access 12 it will be the preferred
method for sharing Access data between multiple locations (with Jet
replication deprecated), but I don't know what that means on a
practical basis.

I see SharePoint as mostly a Microsoft marketing tool designed to
make you buy more Microsoft software and to keep your applications
wedded to Microsoft's products. For that reason, whatever benefits
it may bring seem to me to be worthless.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 22 '06 #2

P: n/a
In message <1t********************************@4ax.com>,
"(PeteCresswell)" <x@y.Invalid> writes
Got a sample of MS's "Advisor Guide To Microsoft Access" in the mail today -
accompanied by a sample "Advisor Guide To Microsoft SharePoint".

I skimmed both, but the SharePoint explanation is too abstract - it's going
right over my head.

Can somebody explain, in simple/concrete terms what MS SharePoint is?


The technology is straightforward, the applications are far from it.
Sharepoint is a content-management system for the IIS web server. It
holds the contents of the web site in an SQL Server database. The web
server delivers virtual folders that function in very similar ways to
folders and files on disk, except that everything is inside the
database.

For Microsoft it's a way of tying users to MS web and database servers
for file storage. Users get an effective way of sharing documents,
customisable metadata and a search-engine that can index all of the
documents stored in Sharepoint, all of the files on disk and also
external web sites (Sharepoint can spider Internet sites.)

If you know what Microsoft has been trying to do with its database as
disk operating system you have some idea of what Sharepoint does, or
tries to do. If you expect to work with Microsoft document-sharing
systems then you have to understand Sharepoint. For some organisations
it is going to replace disk storage. Their documents will only exist
inside Sharepoint.

--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author.

Mar 23 '06 #3

P: n/a
Per Bernard Peek:

For Microsoft it's a way of tying users to MS web and database servers
for file storage. Users get an effective way of sharing documents,
customisable metadata and a search-engine that can index all of the
documents stored in Sharepoint, all of the files on disk and also
external web sites (Sharepoint can spider Internet sites.)

If you know what Microsoft has been trying to do with its database as
disk operating system you have some idea of what Sharepoint does, or
tries to do. If you expect to work with Microsoft document-sharing
systems then you have to understand Sharepoint. For some organisations
it is going to replace disk storage. Their documents will only exist
inside Sharepoint.


Suppose somebody has an MS Access application that generates and saves copies of
various customized form letters.

Right now, they're saving into the database a DOS path the actual .doc file.

Would SharePoint be an alternative place to put the document? i.e. They's
still just store a pointer, but instead of a DOS path it would be the PK of a
SharePoint record and they'd be able to retrieve it via some kind of API call or
just some SQL?
--
PeteCresswell
Mar 24 '06 #4

P: n/a
In message <5c********************************@4ax.com>,
"(PeteCresswell)" <x@y.Invalid> writes
Per Bernard Peek:

For Microsoft it's a way of tying users to MS web and database servers
for file storage. Users get an effective way of sharing documents,
customisable metadata and a search-engine that can index all of the
documents stored in Sharepoint, all of the files on disk and also
external web sites (Sharepoint can spider Internet sites.)

If you know what Microsoft has been trying to do with its database as
disk operating system you have some idea of what Sharepoint does, or
tries to do. If you expect to work with Microsoft document-sharing
systems then you have to understand Sharepoint. For some organisations
it is going to replace disk storage. Their documents will only exist
inside Sharepoint.


Suppose somebody has an MS Access application that generates and saves
copies of
various customized form letters.

Right now, they're saving into the database a DOS path the actual .doc file.

Would SharePoint be an alternative place to put the document? i.e. They's
still just store a pointer, but instead of a DOS path it would be the PK of a
SharePoint record and they'd be able to retrieve it via some kind of
API call or
just some SQL?


I assume that there must be a way of interrogating the database using
SQL but I've never investigated it. If your application supports
Sharepoint you just give a URL as the filename when saving the file, the
OS and Sharepoint handle the rest. Anyone else wanting to retrieve the
file just needs the URL but only needs to use a browser. It's similar to
the way you might use web folders now.

Linux can provide file storage and a database but can't, to the best of
my knowledge, replicate the Sharepoint functionality. I'm sure it will
in due course. For the moment if you need Sharepoint then you have to
have a Windows server, a version of SQL Server and at least Sharepoint
services if not Sharepoint Portal Server. As Sharepoint Services are
bundled with Windows 2003 and you can use the free SQL Server 2005
Express I can see Sharepoint being widely adopted, particularly in SMEs.

--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author.

Mar 24 '06 #5

P: n/a
Per Bernard Peek:
I assume that there must be a way of interrogating the database using
SQL but I've never investigated it. If your application supports
Sharepoint you just give a URL as the filename when saving the file, the
OS and Sharepoint handle the rest. Anyone else wanting to retrieve the
file just needs the URL but only needs to use a browser. It's similar to
the way you might use web folders now.


Aside from using URLs instead of a PKs how would using SharePoint be different
from storing BLOBs in a SQL Server DB?

I'm guessing that the main diff would be fewer layers for the end application to
go through and, maybe, a sort of transparency that would enable any browser that
accepts a URL to retrieve the document in question with no programming changes
needed.

?
--
PeteCresswell
Mar 24 '06 #6

P: n/a
In message <o1********************************@4ax.com>,
"(PeteCresswell)" <x@y.Invalid> writes
Per Bernard Peek:
I assume that there must be a way of interrogating the database using
SQL but I've never investigated it. If your application supports
Sharepoint you just give a URL as the filename when saving the file, the
OS and Sharepoint handle the rest. Anyone else wanting to retrieve the
file just needs the URL but only needs to use a browser. It's similar to
the way you might use web folders now.
Aside from using URLs instead of a PKs how would using SharePoint be different
from storing BLOBs in a SQL Server DB?


Sharepoint is an end-user tool as much as it is a developer's tool. It's
a reasonably easy way for any user with the appropriate permissions to
create and edit web pages on an intranet. For instance they could create
a new folder on the server, save files on it, notify selected people
that it exists and set up a discussion forum. Sharepoint will track
document versions and you can set up a system where interested parties
can have the system notify them of any changes to the files or posts to
the forum.

There are third-party plugins that extend the functionality, or you can
use HTML/ASP if you want.

Sharepoint is mostly going to be used with Active Directory and
Exchange. The server can use AD and Exchange accounts for authentication
and can show different pages to people in different groups.

Sharepoint is a big subject and I'm not by any means the world's
greatest expert on it. I'm an IT Manager who has seen one person use
Sharepoint to set up intranet and extranet sites in two days each. I
made coffee and encouraging noises while he did them.

I'm guessing that the main diff would be fewer layers for the end
application to
go through and, maybe, a sort of transparency that would enable any
browser that
accepts a URL to retrieve the document in question with no programming changes
needed.


Yes. At the risk of sounding like a shill for Microsoft, if you want to
try it Microsoft will send you an evaluation version if you ask them.
The evaluation kit has a copy of Windows 2003 and Sharepoint. You can
try the Sharepoint services that are built into Windows 2003 or install
the full-blown Sharepoint Portal Server.

I'm not sure how Office 12 and Sharepoint will play together. My guess
is that MS will want to tie them together very strongly.

I haven't looked at how Access 2003 and Sharepoint work together either.
In the job where I worked with Sharepoint I did almost no work with
Access other than using it as a front-end to populate SQL Server tables
that were then used to feed simple HTML pages in Sharepoint.

--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author.

Mar 25 '06 #7

P: n/a
Bernard Peek <ba*@shrdlu.com> wrote in
news:WC**************@shrdlu.com:
I'm not sure how Office 12 and Sharepoint will play together. My
guess is that MS will want to tie them together very strongly.


On the Access 12 blog, Sharepoint has been mentioned quite
frequently. The new multi-value data type is being implemented
entirely for consistency with the corresponding Sharepoint datatype.
And while Jet replication will continue to be supported via the
maintenance of backward compatibility, the preferred method for data
sharing will now be via Sharepoint services, with replication
deprecated (according to my understanding of what's been written on
the Access 12 blog).

This shows a pretty significant degree of integration of Access 12
with Sharepoint.

And it disturbs me greatly.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 25 '06 #8

P: n/a
In message <Xn**********************************@127.0.0.1> , David W.
Fenton <XX*******@dfenton.com.invalid> writes
Bernard Peek <ba*@shrdlu.com> wrote in
news:WC**************@shrdlu.com:
I'm not sure how Office 12 and Sharepoint will play together. My
guess is that MS will want to tie them together very strongly.


On the Access 12 blog, Sharepoint has been mentioned quite
frequently. The new multi-value data type is being implemented
entirely for consistency with the corresponding Sharepoint datatype.
And while Jet replication will continue to be supported via the
maintenance of backward compatibility, the preferred method for data
sharing will now be via Sharepoint services, with replication
deprecated (according to my understanding of what's been written on
the Access 12 blog).

This shows a pretty significant degree of integration of Access 12
with Sharepoint.

And it disturbs me greatly.


OK. That news doesn't surprise me. Sharepoint is here and if you want to
do anything non-trivial with MS Office 12 then you probably need to
understand Sharepoint.

Looking beyond Vista and Office, 12 I think MS may be trying to
implement a virtual filing system that merges domain-wide storage into a
seamless SAN. Physical location of data will perhaps be invisible to
end-users.

--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author.

Mar 25 '06 #9

P: n/a
Bernard Peek <ba*@shrdlu.com> wrote in
news:YF**************@shrdlu.com:
In message <Xn**********************************@127.0.0.1> , David
W. Fenton <XX*******@dfenton.com.invalid> writes
Bernard Peek <ba*@shrdlu.com> wrote in
news:WC**************@shrdlu.com:
I'm not sure how Office 12 and Sharepoint will play together. My
guess is that MS will want to tie them together very strongly.
On the Access 12 blog, Sharepoint has been mentioned quite
frequently. The new multi-value data type is being implemented
entirely for consistency with the corresponding Sharepoint
datatype. And while Jet replication will continue to be supported
via the maintenance of backward compatibility, the preferred
method for data sharing will now be via Sharepoint services, with
replication deprecated (according to my understanding of what's
been written on the Access 12 blog).

This shows a pretty significant degree of integration of Access 12
with Sharepoint.

And it disturbs me greatly.


OK. That news doesn't surprise me. Sharepoint is here and if you
want to do anything non-trivial with MS Office 12 then you
probably need to understand Sharepoint.


I think that's an artificial imposition on Microsoft's part, not
anything natural to Office. None of my clients are clamoring for the
features Sharepoint offers.
Looking beyond Vista and Office, 12 I think MS may be trying to
implement a virtual filing system that merges domain-wide storage
into a seamless SAN. Physical location of data will perhaps be
invisible to end-users.


It would be nice if MS would implement such things based on
industry-wide standards, instead of building them around proprietary
software.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 25 '06 #10

P: n/a
David W. Fenton wrote:
Bernard Peek <ba*@shrdlu.com> wrote in
news:YF**************@shrdlu.com:
It would be nice if MS would implement such things based on
industry-wide standards, instead of building them around proprietary
software.


I haven't followed it closely, but from what I've read the OS that will
be released as Vista, was originally planned to contain a completely new
file system that was somehow driven by a database engine. The project
was pulled a few months ago because it wouldn't be ready in time and
would delay the release of Vista (which has happened anyway).

I was pleased, however, to learn that the new Windows server version
will contain NFS server functionality. MS is fighting hard to take over
the server market the way they did with the desktop.

--
Randy Harris
tech at promail dot com
I'm pretty sure I know everything that I can remember.
Mar 26 '06 #11

P: n/a
In message <G8*****************@newssvr27.news.prodigy.net> , Randy
Harris <pl****@send.no.spam> writes
David W. Fenton wrote:
Bernard Peek <ba*@shrdlu.com> wrote in
news:YF**************@shrdlu.com: It would be nice if MS would
implement such things based on
industry-wide standards, instead of building them around proprietary
software.


I haven't followed it closely, but from what I've read the OS that will
be released as Vista, was originally planned to contain a completely
new file system that was somehow driven by a database engine. The
project was pulled a few months ago because it wouldn't be ready in
time and would delay the release of Vista (which has happened anyway).


It was originally planned for release (I think) with Windows 95, then
98, then 2000 and XP. It's been a long time coming. Sharepoint looks
like being an interim release of something similar.

--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author.

Mar 26 '06 #12

P: n/a
In message <Xn**********************************@127.0.0.1> , David W.
Fenton <XX*******@dfenton.com.invalid> writes

OK. That news doesn't surprise me. Sharepoint is here and if you
want to do anything non-trivial with MS Office 12 then you
probably need to understand Sharepoint.
I think that's an artificial imposition on Microsoft's part, not
anything natural to Office. None of my clients are clamoring for the
features Sharepoint offers.


I agree, but having seen what it's capable of I might well adopt
Sharepoint storage if I was setting up a new company operation. The last
place I worked set up a complex knowledge-management system before I
went there, hiring lots of external consultants. I could have done a
better job by moving their document store to Sharepoint and tweaking the
document metadata settings. Just *using* the existing metadata options
in MS Word would have achieved 90% of what they wanted within a day and
at zero cost.

That's another example of what we are seeing in this thread. There are
existing technologies that can do a lot more if you have someone who
knows how to use them. Document metadata is one, Sharepoint is another.

Looking beyond Vista and Office, 12 I think MS may be trying to
implement a virtual filing system that merges domain-wide storage
into a seamless SAN. Physical location of data will perhaps be
invisible to end-users.


It would be nice if MS would implement such things based on
industry-wide standards, instead of building them around proprietary
software.


Agreed, but I don't begrudge them the money if what they do is genuinely
useful. Using proprietary standards gives them an edge to make a profit
from the technology until Open Source and Open Standards create a
commodity market. Intellectually I prefer open standards but I'll
tolerate proprietary ones if they create a product that's worth the
money and the potential lock-in risks. It's a commercial decision. Right
now I believe that Sharepoint could be a major advance if more people
understood its capabilities, but it does mean being locked in to
Microsoft Office and Microsoft server operating systems. The fact that
very few people in a newsgroup devoted to a Microsoft Office product
seem to know about Sharepoint suggests that Microsoft's marketing isn't
working.

--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author.

Mar 26 '06 #13

P: n/a
Bernard Peek <ba*@shrdlu.com> wrote in
news:or**************@shrdlu.com:
The fact that
very few people in a newsgroup devoted to a Microsoft Office
product seem to know about Sharepoint suggests that Microsoft's
marketing isn't working.


Or that the product doesn't live up to its hype. Or that it doesn't
serve a need that many organizations actually have.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 26 '06 #14

P: n/a
>t would be nice if MS would implement such things based on
industry-wide standards, instead of building them around proprietary
software.

nice... but understandable that they dont... it's starting to look like
the migration to database driven virtual filing systems. If they based
that on open standards it would open up half their OS. heaven forbid!

Mar 27 '06 #15

P: n/a
If you are trying to use curreent MS Access with it, here are some
thoughts.

1) To update an item in a sharepoint "table/View" Access CANNOT do it.
It can point to it but you HAVE to use the link in the linked
Sharepoint table to actually update it.

It is NOT Access's table, it belongs to Sharepoint.

2) I have NOT found any way to dump data into sharepoint via Access.

3) SP will "export" to Excell and Access but access must consider it a
linked table in the same manner that Excell can be linked to other
spreadsheets and have data from them but they have to be refreshed.

4) There is another product that they sell that will allow web based
updated sort of like Access's web pages.

5) The best comparison I can come up with relative to view updating is
to consider it a more or less usable way of sharing a single
spreadsheet on a network drive (or server) and more easily allow more
than one person to get into it at the same time.

6) As of right now I have not been able to find any real mechanism for
anything but the simplest type of editing logic for data within the
view.

7) It does have an advantage in this situation that people on multiple
servers can get to the "file/view" a lot more easily and faster than a
"mdb" shared accross servers (which does not work well at all).

8) Read item 5 again and don't expect more than that and if that is all
you need, it may work just great for you. (That is without spending
even more money to try for the rest of the software you will probably
want and need.)
We use it at our sight but I have had to treat it the same as a shared
- imported spreadsheet that I then use Access to massage and extract
summary information from.

Ron

Mar 27 '06 #16

This discussion thread is closed

Replies have been disabled for this discussion.