1

Im writting a C#, .Net3.5, 3 tier web application with ASP.Net front end, SQL server back-end, interfacing with them via TableAdapters and stored procedures. I've stumbled across some odd functionality. I have a AdminUsers table with columns

UserID int NOT NULL
Username varchar(20) NOT NULL
Hash varchar(50) NOT NULL
Salt varchar(50) NOT NULL
Email  varchar(50) NOT NULL

As part of my authentication process for login, I search the table for the supplied username before comparing passwords. This fails because each entry for each varchar column in the table, when returned via the TableAdapter GetData statement, is right padded with spaces to 15 chars ie.

loginUsername = "joe"

storedUsername = "joe "

Interestingly enough the value stored in the DB is correct, I traced the insertion of a row to ensure this. A Datagrid displaying this table is also displayed correctly. The issue only appears when Im calling the following method,

public static bool CheckIfUsernameAvailable(string username) {
        AdminUsersDataTable data = DataCalls.GetAdministers();
        foreach (Data.MissionEducate.AdminUsersRow row in data) {
            if (row.Username == username) {
                return false;
            }
        }
        return true;
    }

public static Data.MissionEducate.AdminUsersDataTable GetAdministers() {
        AdminUsersTableAdapter tblApt = new AdminUsersTableAdapter();
        return tblApt.GetData();
    }

And the GetData() basically calls SELECT * FROM AdminUsers

Any suggestions why spaces would be appended to the end of a tableAdapters select commands results? It doesn't seem that the data is stored like this. Do table adapters display this behaviour often? What more information could I provide?

Much thanks.

Community
  • 1
  • 1
sMaN
  • 3,667
  • 4
  • 23
  • 33
  • I'd want to check out the AdminUsersTableAdapter class. – John Pick Feb 20 '11 at 03:27
  • 2
    There's no way the built-in ADO.NET code would do this, or at least, no way that you would be the first person to notice it. – John Saunders Feb 20 '11 at 04:04
  • Would the fact Im adding hashed values to the table confuse the select result set? it's bit left field... – sMaN Feb 20 '11 at 23:02
  • Ive looked through the variables set for the table adapter, the only of interest is MaxLength=20; I dont think this is an issue, but I can't see any other variables that could create this behavior. Could there be one I'm overlooking? – sMaN Feb 20 '11 at 23:29

1 Answers1

1

It appears the history of the table would provide the information needed to solve this issue. When original creating the DB Table I used the nchar type instead of varchar. Nchar obviously being a fixed length, would pad the values stored within it with enough spaces to be the specified length (15). Funnily enough, I had figured this, and altered the table, deleted and reinserted the values, deleted and recreated the table adapter, but the problem persisted. I solved the issue, however, by dropping the table, deleting the table adapter, deleting associated stored procs, creating a new table with a different name, creating new table adapter with new name, created new stored procs with new name, and solution solved. Fortunately the app is still only in prod, so not too much time lost, but I obviously couldn't have done this with a live app. I don't know what I was missing to allow the nchar's length restriction to persist throughout all my changes.

sMaN
  • 3,667
  • 4
  • 23
  • 33