Editing record in SP submits new record

[Anonymous]

@RandyHayes  Yesterday you were kind enough to assist me in getting my OnSave corrected to show an error for Duplicates on the App ID.  It's working great.  However, I believe I inadvertently broke the ability to edit a record and save without it creating a whole new record.  I'm wondering if the OnSave for SharePoint Integration should have something for the If Edit, do this...If New, do this?  Or any ideas how I can fix it?  Here's what you gave me for reference:

[Anonymous]

Nope, its always 44.  App ID should be the field that is the unique ID - 44 doesn't match any of the App IDs I have.

[RandyHayes]

@Anonymous 

Yes, so there is the issue.  Your app is only ever pulling in the first record of the list and not changing.  This will never work.

There is something wrong with the integration as you should have a selected ID and record coming to your app from the list.

You said you had made a change and things started to not work!?  Did I read that right or was that just in my mind?

If so, what was the change?

To make sure that what I am mentioning above is working (and that there was not some new debacle of a release put out that broke the selection and ID) I just tested this on a list and it is all working properly to get the correct ID's of each record selected.

So, either there was some change you might have made to impact this (potentially fixable), or the integration on your list is somehow not working properly (fixable by a support ticket).

Thoughts?

[Anonymous]

Yes, if I remove what we started with yesterday and just put SubmitForm(SharePointForm1) in the SharePoint Integration OnSave, it allows me to edit and save just fine.  It's only when the dup check gets put back into OnSave that it acts up.

[RandyHayes]

@Anonymous 

No, you are not understanding what I am saying!  First, you NEED that formula in your OnSave.  There is NO problem with that formula!  That formula will give you exactly what you want.  However, the values getting to that formula are not correct.  And, it is not the fault of the formula, it is a problem with the SharePointIntegration.

The tests that we did concluded this...your app was only ever showing the first record ID of the list.  It was never showing any other record.  If that does not work, that has nothing to do with any formulas...that is an issue with the SharePoint Integration!  That needs to work properly or your app is pretty much worthless regardless of any formula.

[RandyHayes]

@Anonymous 

Sorry, I am re-reading though what you said...are you stating that if you remove the formula from the OnSave and put it to just SubmitForm, that the test label that we put in place shows other values beside 44 ??

This is a critical question!

[Anonymous]

No, you're right.  Even that shows 44 still.  I guess I was confused because its allowing an edit if only SubmitForm is in there...so how is it understanding which one to edit if its not tying back at all?  AHHHH...sometimes this can be so confusing, especially as I'm starting out.

[RandyHayes]

@Anonymous 

Yes, the formula would stop the submit form happening (which is what it is supposed to do based on the logic) and that is what you actually want in the OnSave.

The trouble is with this Integration.  It is not working for some reason.

Working with a SharePoint integration is a challenge because of the way that it integrates and you don't have much control over it.

And it seems (in my experience) once it get broken, it is not fixable - except with the direct help from the support team.

Let's check a basic thing...look at your SharePointIntegration object in the app and then look at the DataSource property on it...is it set to [@'Johanna Test List'] ??

The only other potential "try" is to go into the app designer and then click on File and then look at "See all versions".  See if you can restore back an older version where you think things might have worked.

Before you do that, take notes on the label we added to test as you will want to duplicate that in the version you pull back (it will not have it).  Then, try the test again and see if you can get the ID shown to change from 44 to other values based on what you select to edit.

Beyond that, it is either a scrap and build a new list and re-integrate, or put a support ticket in to have them work some magic on the back end to restore the integration.

[Anonymous]

Ok made some progress - I put in just SubmitForm(SharePointForm1) on the OnSave for SPI object.  I also left that test label in there.  When I went into SP and tested, that label IS changing with the entries.  So it appears its not the connection that is bad..which is good.  I am wondering, instead of putting that dup check on the OnSave, if I can't put it on the App ID field so it checks that condition on the OnChange property?

[RandyHayes]

@Anonymous 

If the label value is changing at this point, then the original formula we have for the OnSave should be in place.

OnSave has NO impact on getting the selected record from the list.  So it is not interfering with anything and should be as it was devised. 

Are you stating that NOW the label value is changing with each selection of a different record in your list?  That is the most important part.  What changed that made this now show different values?

[Anonymous]

Yes, the label value is changing now.  The only adjustment I made is removing the original string and putting in the SubmitForm(SharePointForm1).  I completely understand why you're saying it shouldn't change the fact but somehow it is?