Then came web-farming issue just when life started to seem smooth sailing :)

I am planning to utilize ASP.NET 2.0 profiles in my project and everything was good, then came the scenario whereby the UI layer in running on a Web-Farm! Hmmm...

Profiles utilize a local database to keep the info and in a Web-Farm it would be kinda impossible to perform that feat! Good thing Profiles are configurable!

Not only ASP.NET profiles but membership, roles, and web-part personalization also support web-farms!

So what we do is to configure the profiles to read from a central db (in this case, the db that the web farm machines are pointing to). When u modify the state of the profile object, the modifications are saved between visits to the site. So if the request is directed to a different server within the same session (in web-farm scenario), the profile state will be intact, since its stored and accessed out of central db.

So in a web-farm scenario, this is what you should do :

1)Point each machine on the web farm to the same database server to store the profiles. You can set this by changing the connection string on the provider configuration.
   - Since Profiles are API and Schema over database access, there shouldn't be a lot of considerations while shifting the db target from local to the web-farm central db.

2)Now to make profiles use your application's db instead of its own, use the "aspnet_regsql" tool (Window\Microsoft.NET\Framework\[version]) which will let you add the tables utilised by profiles to your own db. Run it without any command line parameters to get the windows wizard that configures all this for you (you can also point to the db used by ur app with this wizard). [OR, run it with the -? option to see all the command line parameter, yea, i know u already know this ;)]

3)So now, the database tables that profiles are using is in ur own application's db (the tables utilized by Profiles, Membership, etc will have a ASP.NET prefix), now go ahead and create relationships between these tables and your own application's tables!

Remember, Adding fields to the tables utilised by profiles is not recomended, unless you write your own provider that can handle these fields!

Cheers!