Develop Reference

How to handle invalid user input table name

I am writing a C# WinForms program which includes a user input textbox, the value of which will be used to create a table. I have been thinking about what the best way to handle invalid T-SQL table names is (though this can be extended to many other situations). Currently the only method I can think of would be to check the input string for any violations of valid table names individually, though this seems long winded and could be prone to missing certain characters for example due to my own ignorance of what is a violation and what is not.
I feel like there should be a better way of doing this but have been unable to find anything in my search so far. Can anyone help point me in the right direction?

As told you in a comment already you should not do this...
You might use something like this
USE master;
GO
CREATE DATABASE dbTest;
GO
USE dbTest;
GO
CREATE TABLE UserTables(ID INT IDENTITY CONSTRAINT PK_UserTables PRIMARY KEY
,UserInput NVARCHAR(500) NOT NULL CONSTRAINT UQ_UserInput UNIQUE);
GO
INSERT INTO UserTables VALUES(N'blah')
,(N'invalid !%$& <<& >< $')
,(N'silly 💖');
GO
SELECT * FROM UserTables;
/*
ID UserInput
1 blah
2 invalid !%$& <<& >< $
3 silly 💖
*/
GO
USE master;
GO
DROP DATABASE dbTest;
GO
You would then create your tables as Table1, Table2 and so on.
Whenever a user enters his string, you visit the table, pick the ID and create the table's name by concatenating the word Table with the ID.
There are better approaches!
But you should think of a fix schema. You will have to define columns (how many, which type, how to name them?). You will feel in hell when you have to query this. Nothing to rely on...
One approach is a classical n:m mapping
A User table (UserID, Name, ...)
A test table (TestID, TestName, TestType, ...)
The mapping table (ID, UserID, TestID, Result VARCHAR(MAX))
Depending on what you need you might add a table
question table (QuestionID, QuestionText ...)
Then use a mapping to bind questions to tests and another mapping to bind answers to such mapped questions.
another approach was to store the result as a generic container (XML or JSON). This keeps your tables slim, but needs to knwo the XML's structure in order to query it.
Many ways to skin a rabbit...
UPDATE
You ask for an explanation...
The main advantage of a relational database is the pre-known structure.
Precompiled queries, cached results, statisics, indexes demand for known structures.
Data integrity is ensured with constraints, foreign keys and so on. All this demands for known names, known types(!) and known relations.
User-specific table names, and even worse: generically defined structures, do not allow for any join, or other typical RDBMS operation. The only approach is to create each and any statement dynamically (string building)
The rule of thumb is: Whenever you think to have to create several objects of for the same, but with different names you should think about the design. It is bad to store Phone1, Phone2 and Phone3. It is better to have a side table, with a UserID and a Phone column (classical 1:n). It is bad to have SalesCustomerA, SalesCustomerB, better use a Customer table and bind its ID into a general Sales table as FK.
You see what I mean? What belongs together should live in one single table. if you need separation add columns to your table and use them for grouping and filtering.
Just imagine you want to do some statistical evaluation of all your user test tables. How would you gather the data into one big pool, if you cannot rely on some structure in common?
I hope this makes it clear...
If you still wnat to stick to your idea, you should give my code sample a try. this allows to map any silly string to a secure and easy to handle table name.

Lots can go wrong with users entering table names. A bunch of whacked out names is maintenance nightmare. A user should not even be aware of table name. It is a security risk as now the program has to have database owner authority. You want to limit users to minimum authority.
Similar to Shnugo but with composite primary key. This will prevent duplicate userID, testID.
user
ID int identity PK
varchar(100) fName
varchar(100) lName
test
ID int identity PK
varchar(100) name
userTest
int userID PK FK to User
int testID PK FK to Test
int score
select t.Name, u.Name, ut.score
from userTest ut
join Test t
on t.ID = ut.testID
join User u
on u.ID = ut.userID
order by t.Name, u.Name

Create and use table referencing two rows of one other table

A tale of three tables: using Entity Framework 6, I need a user-editable table Disallow to store conflicts between rows of another table Option of type Technology.
Like this:
Technology:
ID, PK, [int], not null
Description, nvarchar(40), not null
Option:
ID, PK, [int], not null
Name, nvarchar(20), not null
ADD CONSTRAINT (FK_Tech) FOREIGN KEY [ID] REFERENCES [Technology] (ID)
Disallow:
ID1, [int], not null
ID2, [int], not null
PRIMARY KEY (ID1, ID2) ASC
ADD CONSTRAINT [FK_Valid1] FOREIGN KEY [ID1] REFERENCES [Option] (ID)
ADD CONSTRAING (FK_Valid2) FOREIGN KEY [ID2] REFERENCES [Option] (ID)
As I understand it, after importing the database into the model the user should be able to add records from the EF model so that e can specify that when choosing technology options, it should be disallowed to choose two particular options together.
I have spent much time looking for help on using multiple foreign keys into a single table and was able to create the table successfully in SQL Server and I think I understand the issues there.
But when I attempt to import into EF, an association is shown, on the Options table, but nothing else. How can I add rows if there is no mapping to the table? And then I found a link telling me that there is no way to reference a foreign key. So I added two additional fields, but even after numerous attempts -- following the advice of many links on THAT topic -- failed to bring the table into the model. How can I ensure (1) that the IDs added to the Disallow table are found in Option, and (2) still reference them in EF?
Or perhaps better said, how can I accomplish what I want: rows of conflicts that my code will use to limit the selection of options?

EF Frustration mapping a view to an object

I have a table that hold records of part numbers for a specific project like so:
create table ProjectParts
(
PartNumber varchar(20) not null,
ProjectID int not null,
Description varchar(max) not null,
primary key nonclustered (PartNumber, ProjectID)
);
I have a view that will collect inventory information from multiple places, but for now I basically have a skeleton:
create view ProjectQuantities as
select distinct
pp.PartNumber,
pp.ProjectID,
0 as QtyOnHand,
0 as QtyOnOrder,
0 as QtyCommitted
from
ProjectParts pp;
So far, so good. I go into EF designer in Visual Studio (I already had an object model using the ProjectParts table) and update the model from the database. I select the ProjectQuantities view, click ok.
EF tries to divine the key on the table as a combination of all columns, but I fix that so the key for the object is the PartNumber and ProjectID columns. I check to make sure this validates, and it does.
Next, I add an 1:1 association between the ProjectPart object and the ProjectQuantity object in the EF UI and click OK. Now, when I try validating, I get the message Error 11008: Association 'ProjectQuantityProjectPart' is not mapped. Seriously? It can't figure this out? Alright, I select the link, go to the Mapping Details, and add the ProjectParts table. It adds both tables and meshes up the key relationships. My job is done. I run the validation.
No luck for me. Now I get the error Error 3021: Problem in mapping fragments starting at line (line number): Each of the following columnes in table ProjectParts is mapped to multiple conceptual side properties. The the message lists the ProjectID and the PartNumber columns and their references to the association I just created.
Well duh! Of course there are multiple references! it's a 1:1 compound key, it has to have multiple references!
This is stopping me from getting stuff done. Does anyone know a simple way to fix this so I can collect Quantity information when I'm collecting data about a project and its parts?
Thanks!

You may find this article useful http://blogs.u2u.be/diederik/post/2011/01/31/Building-an-Entity-Framework-40-model-on-views-practical-tips.aspx

Modification in Database due to use of GUID (uniqueidentifier)

The application I have completed has gone live and we are facing some very specific problems as far as response time is concerned in specific tables.
In short, response time in some of the tables that have 5k rows is very low. And these tables will grow in size.
Some of these tables (e.g. Order Header table) have a uniqueidentifier as the P.K. We figure that this may be the reason for the low response time.
On studying the situation we have decided the following options
Convert the index of the primary key in the table OrderHeader to a non-clustered one.
Use newsequentialid() as the default value for the PK instead of newid()
Convert the PK to a bigint
We feel that option number 2 is ideal since option number 3 will require big ticket changes.
But to implement that we need to move some of our processing in the insert stored procedures to triggers. This is because we need to trap the PK from the OrderHeader table and there is no way we can use
Select #OrderID = newsequentialid() within the insert stored procedure.
Whereas if we move the processing to a trigger we can use
select OrderID from inserted
Now for the questions?
Will converting the PK from newid() to newsequentialid() result in performance gain?
Will converting the index of the PK to a non-clustered one and retaining both uniqueidentifier as the data type for PK and newid() for generating the PK solve our problems?
If you faced a similar sort of situation please do let provide helpful advice
Thanks a tons in advance people
Romi

Convert the index of the primary key in the table OrderHeader to a non-clustered one.
Seems like a good option to do regardless of what you do. If your table is clustered using your pkey and the latter is a UUID, it means you're constantly writing somewhere in the middle of the table instead of appending new rows to the end of it. That alone will result in a performance hit.
Prefer to cluster your table using an index that's actually useful for sorting; ideally something on a date field, less ideally (but still very useful) a title/name, etc.

Move the clustered index off the GUID column and onto some other combination of columns (your most often run range search, for instance)
Please post your table structure and index definitions, and problem query(s)
Before you make any changes: you need to measure and determine where your actual bottleneck is.
One of the common reasons for a GUID Primary Key, is generating these ID's in a client layer, but you do not mention this.
Also, are your statistics up to date? Do you rebuild indexes regularly?

Setting IsPrimaryKey=true on column in table with no primary key

I'm writing a quick app using LINQ to SQL to populate a db with some test data and had a problem because one of the tables had no primary key as described by this bloke Can't Update because table has no primary key.
Taking the top answer I added the IsPrimaryKey attribute to an appropriate column and the app worked even though the I haven't changed the db table itself (i.e. there is still no primary key).
I expect it will be ok for my current intentions but are there any side effects which may come from having a table without a primary key seen as having one by the LINQ object?
(I can only think it might be a problem if I tried to read from a table (or populate to a table) with data where the 'primary key' column has the same value in more than one row).

When using an ORM framework, you can simulate keys and foreign keys at ORM level, thus "hiding and overriding" the database defined ones.
That said, that's a practice that I wouldn't recommend. Even if the model is more important than the database itself, the logical structure should always match. It is ok doing what you did if you're forced to work with a legacy database and you don't have the possibility to fix it (like adding the PK on the table). But try to walk the righteous path everytime you can :)
Tables without a PK = Pure Evil.

Basically if all the table updates go through the LINQ object you should be fine. If you have a DBA that decides to modify data directly though SQL then you can quickly run into issues if he duplicates a row with the same PK value.