"Initializing" a dataverse record variable/collection field to Blank()

[HansHeintz]

I sometimes need to set a variable that represents a record in a dataverse table to blank.

(f.e. i am building a collection and the column I want to use for a record is empty to begin with but will be filled later in an updateif)

I might get away with just setting it to Blank() but initializing variables to another type then elsewhere in the app can be catastrophic, not immedeately but after saving and reopening the app. Potentially hundreds of errors and you don't know where to begin correcting.

Can I safely initialize such a variable as

{MyRecord:Defaults(MyTable)}

like in a append patch or is that improper and potentially dangerous use of this syntax?

[Amik]

@HansHeintz so long as the record schema populated in the variable is consistent across your entire app, using Defaults will be fine. You may also safely use the empty operator: {}

Set(
    gbl_MyRecord,
    {}
)

[HansHeintz]

I tried but if in

,UpdateContext({lPleegAccount:If(lStayDetail.Location='Stay Detail Location Choices'.'Foster Family',lStayDetail.Account,Defaults(Accounts))})

I replace Defaults(Accounts) in {} I get errors in code trying to refer to fields of the record variable (of course)

[Amik]

@HansHeintz - why would you not expect an error to occur here? 

You're trying to populate a local Context Variable with a GUID data type ( Account ), but then elsewhere you're also trying to populate the same variable with a Record data type ( Accounts )

[HansHeintz]

Both Defaults(Accounts) as lStayDetail.Account are reported as datatype:Record if I higlight them in the editor. 

lStayDetail.Account refers to a lookup datafield in another table: Accounts. 

Defaults(Accounts) does not compute to Blank() so that could be a problem. Mayby I'd need another function {lStayDetail.Account : Blank(Accounts)}. Or check for IsBlank(lPleegAccount.Account) it it comes to that.

[Amik]

@HansHeintz - how is "lStayDetail" being generated? Is that derived from a Control or a Collection?

[HansHeintz]

In my example It is a context variable created at this line. But my questions stems from numerous instances where assigning a record to a record variable or collection field does not leed to errors at once but only after saving and reopening the app. When you have done a lot of editing in a session and there may be many dependencies on the error I encounter hundreds of errors and often don't even know where to begin. This is where the lack of strong typing in powerapps (probably to be able to call PA low code) really starts to hamper productivity.

[HansHeintz]

I thougt of another way:

UpdateContext({lPleegAccount:LookUp(Accounts,false)})

Hope that doesn't get me a lookup time penalty 😉

[Amik]

@HansHeintz - ideally Power Apps should immediately inform the user of a incompatible type error when a conflict occurs. I suspect some initialisation is performed in the background whenever the app is restarted, and it is only at that point when Power Apps identifies a conflict in data types between variables. @CarlosFigueira will have better insight on this behaviour.

Back to the problem, your response still does not answer what lStayDetail is / how it is being generated.

[HansHeintz]

lStayDetail is initialized as a context variable

;UpdateContext({lStayDetail:First(
                                  SortByColumns(
                                                Filter('Stay Details',Stay.Stay=lStay.Stay)
                                                ,"doa_from"
                                                ,SortOrder.Descending
                                                )
                                  )
              })

But there is no specific problem. My initial question is about making sure record variables are or type table.record even if they start without a value. LookUp(table,false) would perhaps be most elegant if it doesn't cost time. I could test for that.