In PostgreSQL, you could do such a thing using a
-- A change of mind...
WITH first_update AS
gender = 'FEMALE'
applicationnumber = 12345
gender = first_update.gender
studentprofile.applicationnumber = first_update.applicationnumber ;
You take advantage of the fact that PostgreSQL can update a table within a
WITH (which, AFAIK, isn't standard SQL), plust the fact that you can have some
RETURNING data from it (again, non-standard SQL), and use this data to make a second update.
Notice that you only need to write your parameters (12345, 'FEMALE') once.
You can see the whole setup at dbfiddle here
NOTE: I wouldn't do this kind of things. I'd try to have the data normalized and not redundant. There are very few scenarios where this kind of thing should be done for performance or security reasons.
You use this type of structure (WITH RETURNING ...), in some occasions, when you want to
INSERT data into a table, and get a surrogate key (a
SERIAL, or a
UUID, or some other automatically generated id) that you use to
INSERT into a surrogate table.
As an alternative (that can be also implemented in most other databases, with adequate syntax changes) you could write a stored procedure (in PostgreSQL, they're actually User-defined Functions, to do the same thing:
set_student_gender (in _applicationnumber integer, in _gender text)
UPDATE studentbase SET gender = _gender WHERE applicationnumber = _applicationnumber ;
UPDATE studentprofile SET gender = _gender WHERE applicationnumber = _applicationnumber ;
LANGUAGE PLPGSQL ;
... and you'd use
set_student_gender(12345, 'FEMALE') ;
As a second alternative: go for a trigger, as already suggested by @Robert Carnegie. The principle is the same, only the syntax of trigger functions is different when you use different SQL RDBMS.