We Keep Coding

Id in Database what datatype use?

I am working with Access database for a C# winform application.I want to create software, which stores the patient's details.I have assigned a patient_Id for each patient, Patient_Id is of "AutoNumber" datatype so that it will automatically increment. My problem is when same patient comes again then New Patient_Id automatically generated to store his new current data, but for same patient I want only one ID.

Use some unique data as a field in your patient table (such as social security) and when a patient comes, look up this unique number and determine if he is a new patient or a returning one. This is a simple SELECT query something like:
"SELECT patient_Id FROM tPatients WHERE SSN=#sNum"

Multiple users but storing data in same tables

Hi I am new to databases in general, so forgive my noob question below, but I really do need help.
I have designed a database with 4 tables. I have created an application in C# which will store some values in these 4 tables during the course of the application running. However, this is all working fine when there is only one user of the application, but if more that one user is going to use the same application running in an ASP.NET page, then they will be accessing and altering the data in the 4 tables, and problems will soon arise.
My question is, how do I prevent this from happening? I want each user to have their own unique username and then use that to differentiate them in the tables but my knowledge of databases is limited to know how to achieve this. Please help?

Supposing you have the following table today:
FavoriteFood
—————————————
FoodId
FoodName
And it lists all of your favorite foods. But then you decide you'll let me use your database to store my favorite foods too. Since you don't care about my favorite foods, and I don't care about yours, you need a way of keeping them separate. First, you'll create a User table:
User
—————————
UserId
UserName
FirstName
LastName
Then, you need to relate the User table to the FavoriteFood table. One way of doing this would be to add a Foreign Key to the FavoriteFood table. Give it a new field called UserId:
FavoriteFood
—————————————
FoodId
UserId
FoodName
Then you can get just the food for a single user by adding a WHERE clause to your SQL code:
SELECT FoodName
FROM FavoriteFood
WHERE UserId = #UserId
That could be ok, but I'm not satisfied with it. This database is not normalized! Suppose, you later want to store calorie information about your foods. You add a field called calories to your FavoriteFoods table. As you are populating that field with data, you notice that you are putting in the same data multiple times. All of your users like bananas, so you have as many entries in your table for bananas as you have users. You have to enter the exact same calorie information over and over again. Instead, you should have all the information for a food in the table just once, and use a completely separate table to map food to users:
Food
—————————
FoodId
FoodName
Calories
FavoriteFood
—————————————
FoodId
UserId
Use a join to get the favorite food for a user:
SELECT f.FoodName
,f.Caloires
FROM Food f
JOIN FavoriteFood a ON a.FoodId = f.FoodId
WHERE a.UserId = #UserId

Multiple database records

I want to store emergency help line contacts in database from ASP.NET web site . . .this contacts will be assign to particular locations of different cities. . .
For eg: City=Mumbai and then for Mumbai City there will be various locations like Dadar, Andheri, Borivali , etc .
I have designed a form
now, the problem is that , there can be one airport for multiple locations of a particular city then also i have to enter the entire information for each and every location . . . So is there any way to avoid multiple entries ?

You can use following table schema, and design you form accordingly
Location Table
LocationID (Primary Key)
CountryID (Foreign Key)
CityID (Foreign Key)
ContactID (Foreign Key)
Location
City Table
CityID(Primary Key)
City
Country Table
CountryID(Primary Key)
Country
Service Table
ServiceID(Primary Key)
Service --Airport/Ambulance/fire...
Contact Table
ContactID (Primary Key)
ServiceID (Foreign Key)
Description --AirportName/HospitalName
Contact --Contact Number
UPDATE (Form Design Tips)
Form to add records to City/Country/Service Tables (They are quite simple you just need to check duplicate entry/ Required fields.
For Contact Table use Drop Down for Service that is populated from Service Table
For Location use Drop Downs for Country,City and Contact that are populated from respective tables.
Use INNER JOINS to join the tables and display the desired Results

Making a page where each user has his own information,gridview etc

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.):
Users
----------
ID
Name
etc.
Products
----------
ID
Name
etc.
Orders
----------
ID
UserID
DateOrdered
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:
OrderedProducts
----------
OrderID
ProductID
Then, for displaying in the UI, you would query the data to get only the products ordered by that user:
SELECT DISTINCT
Products.ID,
Products.Name,
Orders.OrderedDate
FROM
Users
INNER JOIN Orders ON Users.ID = Orders.UserID
INNER JOIN OrderedProducts ON Orders.ID = OrderedProducts.OrderID
INNER JOIN Products ON OrderedProducts.ProductID = Products.ID
WHERE
Users.ID = #userID
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.

You certainly DO NOT need a separate table for each of your users!
Why don't you just add an additional column to one of your tables to store the username. This way, each record is marked to belong to specific user. Reading the data for logged user is just a matter of simple Where clause on the table.

No thats not right,
You can't create a table for every user. Think if you have 10,000 users than you mean your database contain 10,000 users.
You have to create only one table in which all user's information is saved.
You have to save an identity like user name or email to your database and
When user login to your app by his username or email the information will be taken from table on the basis of username or email and set to gridview.
May it helps you...

this is not Logical to create a table for each user,save all user information in a table is better and faster
for this your can make a table for user information with a user id, and another table for user data entery.and make a relation ship between them

Database design

I have a database in which I store product sales. My sales table is made up of the following fields: [saleID], [itemCode], [Date], [storeID], [quantitySold]. The problem is I want the user to be able to insert a payment for multiple saleIDs.
Prices come from the items table but there may be a discount if multiple items are purchased. I want to be able to store a finalPayment field and multiple sales connected to it, then group the sales by the specific finalPayment. However there could be same sum finalPayments that do not belong to the same sales batch so I cannot group by finalPayment as a field in the sales table.
I could create a finalPayments table and every time a multiple item sale and discount is made, store a new final payment in it, retrieve the last finalPaymentID and then store it in the sales table (in a new field [finalPaymentID] that I will create) for every sale that belongs to it. Then i could group sales by finalPaymentID.
Could the last finalPaymentID in the table be created by some other store? Can there be a concurrency problem? Do I need to lock the table in some way until the finalPaymentID is retrieved and stored in the sales table? How would you implement this?

I would create multiple tables.
Table Order would contain OrderId, Date, StoreId
Then I would create an OrderItem Table which would contain OrderId, Item, Qty, Price
There would be a one-to-many relationwhip from the orderItem table to the Order table.
That way you can group by OrderId to get your quantities and values.

Sounds like a cart schema - something like this should do:
Product (your Items table)
- | ProductId | Whatever
Payment
- | PaymentId | Date | Whatever
Cart
- | CartId | UserId | ProductId | PaymentId
For each product, you have a record in Product. Each 'Payment' record is a sum of all the products (the cart total). Each record in sale is a unique identifier to each item in the 'cart', so that you can say UserID 1 has 3 items in his cart for a specific payment Id (3 records).

I actually did with the payments table. I used
string insertSQL = "INSERT INTO [payments ] ([paymentSum]) VALUES (#paymentSum);SELECT ##Identity";
and then stored the paymentID retrieved into the sales table for each sale that is part of the batch.