Single Database User Forms fnConstraintGetLoginName

.frm file

The user forms .frm file will be converted to Single DB with the original file being backed up, per Backups

Permission

The creation of tables should not require any SQL permissions granted

Example form

Sample Table:

CREATE TABLE [finance].[uUserForm](
[seq] [int] IDENTITY(1,1) NOT NULL,
[DebtorID] [int] NULL,
[Details] [varchar](50) NULL
) ON [MAIN]

Sample Lookup Table:

CREATE TABLE [finance].[uluFinanceLookup](
[Code] [varchar](50) NULL,
[Description] [varchar](50) NULL
) ON [MAIN]

Sample User Form code:

[FORM]
Query="uUserForm"
QueryLink="DebtorID"
QueryLinkInSynergy="DebtorID"
Caption="v68 User Form Test"
ShowButtonApply

[Fields]
GroupBox, Width="420", Height="140", Caption="Deposit Details", Level="1"
wwDBLookupCombo, DataField="Details", Left="110", TopRel="25", Width="200", LabelCaption="Code:", LookupQuery="[FINANCE]SELECT Code;Description FROM finance.uluFinanceLookup", LookupField="Code", Selected="Code|15",Selected="Description|50",Level="2"

Additional Finance Databases

Any additional finance databases will convert any finance schema prefixes, as per example form

User Logins

dbo.SynergeticCurrentUser

Some user tables had used default values (constraints) set up against tables.

This is not a supported approach in v68 and will result in the user zSynergetic_main_dbo having updated or modified a record/table.

SYSTEM_USER

SYSTEM_USER has historically been used for user forms to identify users who may have created or modified records in a table.

However, Synergetic now connects to the database as a named user rather than as the actual user.

As a result, SYSTEM_USER would return the same result across all users when logged in to Synergetic.

Rather than SYSTEM_USER, clients should use the new function named dbo.fnConstraintGetLoginName() which will give the required user name.

dbo.fnConstraintGetLoginName()

dbo.fnConstraintGetLoginName()  is simply a wrapper for dbo.fnGetLoginName() and is the recommended function for use within the system to return a user login.

When something is a default constraint, it can't be modified, and Synergetic may need to modifiy this in the future. 

DDL triggers are in place to avoid dbo.fnGetLoginName() being used directly.

ALTER TABLE [dbo].[uExampleTable] ADD  CONSTRAINT [DF_uExampleTable_LoginName]  DEFAULT ([dbo].[fnConstraintGetLoginName]()) FOR [LoginName]
GO

Best Practice in v68

The best practice for having 'Modified By' and 'Modified Date' fields populated is using triggers.

A default value constraint will simply populate a record at the point of entry and will require an additional trigger for any other logic, such as recording updates.

An example of this is as follows:

uExampleTable_IUTR
DECLARE
  @Username VARCHAR(100) = dbo.fnConstraintGetLoginName(),
  @ID INTEGER = dbo.fnGetConfigUserID(''), --Used when you want to save the ID rather than the login name
  @Date DATETIME = GETDATE()

UPDATE
  t
SET
  t.ModifiedDate = @Date
, t.ModifiedBy   = @Username
, t.ModifiedByID = @ID
FROM
  uExampleTable t
INNER JOIN inserted i ON
  i.uExampleTableSeq = t.uExampleTableSeq