ebarro at roadrunner.com
ebarro at roadrunner.com
Thu Jan 7 18:04:56 CST 2010
I completely agree with Jim. Here are a couple more thoughts... 1. Sharepoint does use SQL server. There is a table that stores the list structure and it is stored as XML in several columns. The data is separate. The reason why it's slow is the use of XML and XSL to display the data. 2. You don't need InfoPath to use custom forms. You do need Sharepoint Designer to customize the default CRUD pages (NewForm.aspx, DispForm.aspx, EditForm.aspx) but there are gotchas such as making sure to retain the automatically generated listform webpart by hiding it instead of overwriting it or deleting it and also the potential of disabling the file attachment feature. 3. It would be helpful to learn CAML and Stramit CAML viewer is a helpful tool. 4. You can use jQuery to talk to Sharepoint web services and display any list on any site. ---- Jim Hewson <jm.hwsn at gmail.com> wrote: > Prior to my full-time Access job several months ago, I was a SharePoint > "expert" and consultant for several government agencies. > SharePoint is designed for collaboration between people who are > geographically separated. It does work well for sharing documents, > graphics, and some business processes implementation. However, to say it > can be utilized as a database is just wrong! > Here's why... > 1. SharePoint lists are used as "tables" or "spreadsheets" and can be used > to store a lot of information... however; the limitation for a list is 2,000 > items. Any list with more than that will be extremely slow. That of course > depends on the number of users accessing the site. > 2. SharePoint uses SQL Server as a backend and everything is stored in one > file. How it's stored is a mystery to me. So if you have several lists > with lots of data it could slow down. > 3. To make data input in SharePoint similar to an Access database one would > have to use InfoPath forms and when printing two forms would have to be > created because usually the input form will not print correctly. The buttons > and information items will show on the printed form. > 4. Access 2007 can be utilized as a front end for SharePoint, and the > distribution is relatively simple because it can be placed in one of the > lists. However, remember there is a limit to the lists SharePoint uses. An > Access 2007 database can be uploaded to SharePoint and then the tables for > the database become lists in SharePoint. > 5. Custom coding for input forms can be done... however, in my experience > simple forms take an extraordinary amount of time to develop, test and > implement. > 6. InfoPath forms in SharePoint can use external data such as tables in SQL > Server or Access; however, in my experience they can sometimes be slow. > > That's a good start. > Jim > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Collins, Darryl > Sent: Wednesday, January 06, 2010 11:57 PM > To: Access Developers discussion and problem solving > Subject: [AccessD] Database vs Sharepoint > > Hi all, > > We have a new sharepoint guys working with us who is pretty sure that > sharepoint can do everything our database does, only better, faster and > neater. However, I am less sure. From what I understand Sharepoint is > very good at sharing documents, document control and management, > creating and dealing with simple lists and the like. But AFAIK it > cannot deal with relational, normalised data in any way that we know and > understand. Or high level transactional data? > > I am just a luddite and old school? Or is sharepoint being used like > Excel. That is, it can hold data, therefore it is a database as far as > the users are concerned? > > A quick Google seems to support my theory, I was wondering any there are > any 'war stories' out there. I need to learn more about this upstart > software! > > Anyone got any thoughts on this? > > Cheers > Darryl. > > "This e-mail and any attachments to it (the "Communication") is, unless > otherwise stated, confidential, may contain copyright material and is for > the use only of the intended recipient. If you receive the Communication in > error, please notify the sender immediately by return e-mail, delete the > Communication and the return e-mail, and do not read, copy, retransmit or > otherwise deal with it. Any views expressed in the Communication are those > of the individual sender only, unless expressly stated to be those of > Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any > of its related entities including ANZ National Bank Limited (together > "ANZ"). ANZ does not accept liability in connection with the integrity of or > errors in the Communication, computer virus, data corruption, interference > or delay arising from or in respect of the Communication." > > -- > 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