Using dynamic database name for DML in trigger
What a brittle solution. Does the return value of sfn_GetSecondDbName() really change that often? Where does its value come from? Would be much easier to hard-code the database in the trigger, and change the trigger when that changes, rather than change the function and try to "save work" by not having to update the trigger. 

Your current approach will require nested levels of dynamic SQL, and this becomes more complicated because dynamic SQL can't see the scope where inserted is, so additionally you'll have to dump those contents into a #temp table before you can access them from dynamic SQL. Ugly, ugly, ugly.

ALTER TRIGGER [dbo].[CTR_Production_InsertRecordInDatabase2] 
ON [dbo].[Table1]
FOR INSERT, UPDATE, DELETE
AS
BEGIN
  SET NOCOUNT ON;

  CREATE TABLE #inserted(column1 INT); -- guessing
  INSERT #inserted(column1) SELECT column1 FROM inserted;

  DECLARE 
    @db  SYSNAME = dbo.sfn_GetSecondDbName(), 
    @cmd NVARCHAR(320),
    @sql NVARCHAR(MAX) = N'INSERT dbo.pDM_Production_RecordInfo(column1) 
      SELECT column1 FROM #inserted;';

  SET @cmd = @db + N'.sys.sp_executesql';
  EXEC @cmd @sql;
END
GO


(Also note that nothing will get inserted in the event of a delete, since inserted will be empty.)

Better yet, store this data in a staging table that is in this database, then create a backup job that moves the data to the other database. That way the trigger doesn't have to do all this dynamic dynamic dynamic SQL, and the transaction that called it isn't affected by any delays there or communicating with the other database (think about the fact that another database could be offline, single user, detached, or the customer could have fat-fingered the name when they changed it - do you want any of these things to block DML on the primary?).