Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

FBA user reg data - should I store it in SharePoint?

  Asked By: Deon    Date: Mar 26    Category: Sharepoint    Views: 2912

I have inherited a SharePoint site that utilizes FBA. All of the data
entered about the user during the registration process is stored in
the FBA database (basic ASP.net membership provider tables) and not
stored in SharePoint.

Question #1 ) In SharePoint and FBA is it normal that this is the way
that it is done or should the user data contained in the ASP.Net
Membership provider tables be stored instead in the SharePoint

Question #2) I need to access some of the data stored in the FBA
ASP.Net Membership provider tables for future use in workflows and
email lists. Is it easy to access these tables from a Workflow?

I would like to go with best practices on this - if it is best
practice to have the FBA user data in SharePoint, then I would rather
have it done that way.



4 Answers Found

Answer #1    Answered By: Faith Delgado     Answered On: Mar 26

#1) You cannot store  information in the SharePoint database  unless you put it in
a list. The content databases are off-limits to custom code. There is a
list-backed FBA provider  on CodePlex. (http://www.codeplex.com/SPListMP)

#2) I don't know enough about workflow to speak about what is included, but any
custom code that needs to get the membership  info needs to call the methods of
the interface and provide configuration information. In a web application , that
would be in web.config.

Answer #2    Answered By: Amrita Durgude     Answered On: Mar 26

I've developed several workflows  for a FBA SharePoint (WSS) site  and can
offer some insight into the problems I've had. Workflows created in
SharePoint Designer do not work with FBA WSS sites out of the box when
trying to assign a task to someone. You have to install the "Useful
SharePoint Designer Custom Workflow Activities" on CodePlex
(http://www.codeplex.com/SPDActivities). I used the lookup user  function
to get the ID of the user and stored  it in a variable. Then you can use
the variable to assign the task created. When designing workflows in
Visual Studio, it's basically the same idea. If you know the username,
then you can just append the name of the membership  provider to the
string. For example, if your membership provider  is called "member" and
the username is bsmith then you could use member:bsmith to assign the
task. If the workflow is passed the persons name (for example, when the
person is selected from the people picker web part) then you have to use
the user lookup call. I don't remember off the top of my head the exact
syntax but if you need specific information please let me know and I'll
did it up.

Answer #3    Answered By: Maricela Conway     Answered On: Mar 26

In response to #1 - I understand that. But since the Users are stored
in the User Information list, why couldn't I simply create new site
Column types for the new data  fields and then modify the User
Information List to include those columns?

I have done similar thongs in otehr lists.

Answer #4    Answered By: Vinay Thakur     Answered On: Mar 26

Any changes you make to the database  directly (schema, data, etc) puts
your environment in an unsupported state and can easily lead to
deadlocks, server errors, etc. YOU should NEVER edit the SharePoint
database directly.

That said, if what you are doing is from the UI or the OM/Web Services,
then it should be ok. Your original response made reference to a
database change, not a Content Type change. The former is bad, the
latter is fine. J

Didn't find what you were looking for? Find more on FBA user reg data - should I store it in SharePoint? Or get search suggestion and latest updates.