Binding to a record, and delegation question

[EdHansberry]

A couple of quick questions, I hope, which are more about best practices.

1) I have an app where you can either create a record via a button or edit a record from a gallery. Binding the data on the next screen is easy for edits.

Set(gvarCurrentRecord, galBrowse.Selected)

I can then manipulate the record via gvarCurrentRecord.FieldName.

The user can also create a record. The record is created instantly when they push the + button via a Patch() operation. The main field is an incremented number. So even though they have pressed the New Record button, when they get to the next screen, they are really editing an existing record, just as if they had done it from the Edit button in a gallery. This took me a few min to figure out, but I used this:

Set(
    gvarCurrentRecord,
    First(
        Filter(
            '[dbo].[tblOnMyServer]',
            ItemNumber = gvarNewItemNumber
        )
    )
);

gvarNewItemNumber is an integer that is the next item number to be created.

Now I can access this record the same way. gvarCurrentRecord.FieldName

Is there a problem with doing this, before I go too far down this path? I don't want to get 10 more hrs into this project and realize that is going to be a problem.

2) The formula I am using has a delegation warning, as FIRST() cannot be delegated. But do I care? What I mean is, does delegation totally break down because I used FIRST() or does the FILTER() operation still get delegated, then FIRST() works. FILTER() will only ever return a 1 record table. I just need to convert the table into a record. Is there a better way, or is this ok?

[mdevaney · Accepted solution]

@EdHansberry 
#1 My 'best practice' is to create the record at the moment the new record is submitted.  An example looks like this...

Patch(
    '[dbo].[tblOnMyServer]',
    Defaults('[dbo].[tblOnMyServer]'), 
    {
        FieldName1=InputText1.Text,
        FieldName2=InputText2.Text,
        FieldName3=InputText3.Text
    }
);

That being said, I do not know your technical reason for creating the record in advance.  There could be a good reason!  Doing it will not hurt you later in the project.

I would suggest creating the new record like this...

Set(gvarCurrentRecord, Patch('[dbo].[tblOnMyServer]', Defaults('[dbo].[tblOnMyServer]'))

#2  The FIRST + FILTER combination is actually an anti-pattern.  I used it for awhile before realizing that LOOKUP would retrieve the first matching record vs. FILTER having to go through the whole database before grabbing the FIRST record.  For me LOOKUP resulted in performance gains 🙂

Set(
    gvarCurrentRecord,
    LookUp('[dbo].[tblOnMyServer]', ItemNumber = gvarNewItemNumber)
);

However, if you use my 2nd example in part #1 you won't have to use this code.  gvarCurrentRecord will already have values 🙂

---
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up."

[EdHansberry]

Thanks! Clever on the Patch inside of Set. I didn't know you could do that.

The reason I create the record as soon as they hit the + button is I need that next number in the database. That way, if they stay on the "edit screen" for a few minutes, then someone else goes into the app on their PC and creates a new record, the counter that increments the item number will recognize the in-progress record from user #1.

Otherwise, they would both be assigned the same item number and whoever pressed submit last loses. I know I could handle that by incrementing the item number on submit if needed, but if they press New, and give that number on the screen to someone on the phone or via email before they submit, the 3rd party has a wrong item number.

I'll have to remember the LOOKUP suggestion. Coming from the Power BI side, we try to avoid LOOKUPVALUE() as it is doesn't perform as fast as a FILTER() operation, but the underlying concepts are totally different. And we never have delegation issues. A billion records? No problem! 😁

[mdevaney]

@EdHansberry 

LOL, I envy your ability to perform operations on a million-zillion records with no thoughts of delegation.

Power BI was my first love.  But now I am far better at PowerApps.

---
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up."