After the user logged in , I need a page where each registered user has his own gridview and controls binded to his gridview.
The page will contain a sqldatasource binded to the gridview .
I thought about making a new table in the database for each user and in the form load to get the username after the user logged in, get the table name and replace the sqldatasource bind to his table name and the other controls fields for table name to his one.
Or is there any other way of doing this?
You definitely do not want to make a separate table for every user. How on Earth would you plan to scale that to multiple users?
What data does the user need to see on their page? Understand that a gridview doesn’t have to map directly to a database table. It can map to any set of data. So you can store the data in your database in a way that makes sense to persist it (relational entities), then query and display it in a way that makes sense to display it.
For example (and it’s a contrived example, since we don’t know what data you have), if you have users who need to see a list of products that they’ve ordered, then you wouldn’t create a table of products for each user. You’d probably have a table for each of the entities (User, Product, Order, etc.):
And since each order would have a list of products, and each product can be on many orders, that’s a many-to-many relationship. So you might create a linking table for that relationship:
Then, for displaying in the UI, you would query the data to get only the products ordered by that user:
This should give you a list of distinct products ordered by that user and when they were ordered. (Note that this code is free-hand, I don’t have a database handy to test it.)
So each user would see their own specific information.
You want to make sure that your data is modeled in a usable relational fashion. Define your entities (usually real-world things you’re representing in the data) and define tables to represent those entities. Relate them together in natural ways. Relational databases are great at handling complex queries against well-defined data. Don’t try to design your database around the nature of the display from the perspective of the user, design it around the nature of the information being stored.