New User problems with default and display values

[Oeste]

My first forum post and I am having a problem with default and display values.

1. I have a character field in a list control. I found a default format for social security numbers in the documentation "000-00=0000" but I can't seem to find how to set a display format so that the entire ss number will not show. I would prefer it to show as "xxx-xx-0000" when displayed in a list.
2. I see I can add a default value for a field in a new record, for example DateCreated. But I have an edit button, and would like to add the date in "MM-dd-yyyy" format to a hidden field. Is this a java script action I need to add to the button, and if so, how?
3. I am getting a lot of "Invalid Server Response. Please try again." errors as I use this forum. Is that just me?

[Oeste]

I was able to resolve question 2 and I'm no longer getting the Server error message when logging on to the forum, so all I need is an answer to question 1.

I have a default format for ss # of "(000)-00-0000", but want to display the last 4 digits only whenever data is displayed in a list.
The existing SSN column (character, var 25) stores digits only (no dashes or parentheses).

[mikeallenbrown]

I am getting a lot of "Invalid Server Response. Please try again." errors as I use this forum. Is that just me?

It's not just you. I get this all the time. Made a forum post about it and was told nobody else has reported a problem. Maybe you and me are it.

[madtowng]

I don't understand why you'd create a column length of 25 for a value we know always contains 9 digits without punctuation, but that's another thing.
Why not simply select right(ssn,4) when setting up the list to display.
Option B would be to select right(ssn,4) as 'displayssn' .

[CharlesParker]

I was also having users report invalid response as well, but mainly with the Chrome browser, I could not duplicate it in firefox. It was also only occurring when using Jim Calendar component - when I was able to duplicate it, the error in the console was a pointer to a chrome bug and it was related to the javascript version. All I can think is chrome was using a newer version of the js library that had an issue of some sort - not really an alhpa software issue.

On the issue of the only showing a partial value, you might do well to store ONLY the partial value with the record you are looking up and store the entire thing elsewhere or not at all. Seems a bit risky to even store it, I am assuming you are encrypting it as well. Even a database without a honeypot gets attacked, might be more of a target with something to gain. I know your probably aware, posting for those who might be new to security issues like that, etc.
Even if you are only showing a partial of the full value, the call itself will pull down the entire number then cloak it so it might be exposed when using dev tools to look at the raw data returned...I think even if it's encrypted to and from the DB what gets returned is probably the raw data which again would be exposed. You could create a view within your DB to trim it and very quickly be able to pull read only data without exposing the whole thing.

[madtowng]

I'm providing this as a simple example. If you want to experiment with the code, you can find it >HERE<
This code is created using mySQL but should work with sql Express.
I believe this code as designed will not pull down the entire value.

This code creates the table, adds a before insert trigger, adds 1 row of sample data, and finally executes
a query to display the data from the table.

create table samplenames(
seq int not null auto_increment,
given varchar(15) default null,
middle varchar(15) default null,
surname varchar(25) default null,
ssn varchar(9) not null,
displayssn char(4),
primary key (seq)
);

DELIMITER $$

CREATE TRIGGER beforeInsert_samplenames
    BEFORE INSERT
    ON samplenames FOR EACH ROW
BEGIN
    set new.displayssn = right(new.ssn,4);
END$$    

DELIMITER ;


insert into samplenames (given,surname,ssn) values ('Joseph','Biden','356324336');

select given, surname, ssn, displayssn
from samplenames;

[Oeste]

I don't understand why you'd create a column length of 25 for a value we know always contains 9 digits without punctuation, but that's another thing.
Why not simply select right(ssn,4) when setting up the list to display.
Option B would be to select right(ssn,4) as 'displayssn' .

Hi madtowng!,
I'm providing a new user interface to a legacy application created 12 years ago by a developer who has since left the company. Most of the columns are either 25 or 55 characters in length, even fields that should be logical or bit. Once the UX is done they'll let me tinker with the table structure (even though it would, IMO, be a lot simpler and less expensive to do this now). I'll try your suggestion of right ssn,4 to set up my list display. Thank you!

[Oeste]

It's not just you. I get this all the time. Made a forum post about it and was told nobody else has reported a problem. Maybe you and me are it.

I attended Wednesday's weekly webinar and the presenter mentioned they were now trying to get more folks to use the forum to answer questions rather than sending them to Alpha guides. I was concerned when I saw the error messages as it was my first time post on the forum, but it seems to be pretty stable now.

[madtowng]

Seems like the previous guy was determined to never get a "data too large" error.
I'm confident it'll work if (s)he didn't let garbage data in.

[Oeste]

On the issue of the only showing a partial value, you might do well to store ONLY the partial value with the record you are looking up and store the entire thing elsewhere or not at all. Seems a bit risky to even store it, I am assuming you are encrypting it as well. Even a database without a honeypot gets attacked, might be more of a target with something to gain. I know your probably aware, posting for those who might be new to security issues like that, etc.
Even if you are only showing a partial of the full value, the call itself will pull down the entire number then cloak it so it might be exposed when using dev tools to look at the raw data returned...I think even if it's encrypted to and from the DB what gets returned is probably the raw data which again would be exposed. You could create a view within your DB to trim it and very quickly be able to pull read only data without exposing the whole thing.

Thanks CP, the db is encrypted and I'm using Chrome as well. I'll take a look at Chrome's debugger to make sure the SSN is not viewable unless it's through the UX.

[Oeste]

This code creates the table, adds a before insert trigger, adds 1 row of sample data, and finally executes
a query to display the data from the table.

Awesome!

I'm back in the office Thursday so I'll give it a try .