BUG? 'An entry is required or has invalid value' Azure SQL, Identity Column req field

[PaulD1]

I am developing a PowerApp which uses Azure SQL DB as the data source.

I have a table OrderHeader. The primary key is OrderHeaderID and is an int set as identity(1,1). I have a form which contains OrderHeaderID as a DataCard and for which the default is ThisItem.OrderHeaderID.

When working in the PowerApps web editor, I create a form based on OrderHeader and add the OrderHeaderID as a datacard. I can then add a new OrderHeader in the form on the web editor.

When I publish and run the app in the webplayer, iOS or Win Mobile, when I try to add an OrderHeader I get the error that 'An entry is required or has an invalid value' seemingly because the OrderHeaderID has not been populated.

If I close the app in the PowerApps Web Editor then re-open it, I get the same error when trying to add an OrderHeader, but if I delete the OrderHeaderID data card from the form and then add it again (without modifying any settings) then it works again!

I also have an OrderDetail data source and form with an OrderDetailID card. This behaves exactly the same way.

Thanks

Paul

[Anonymous · Accepted solution]

This could be a longshot, but if you have a TimeStamp data type field in your table, try adding one.

In general, I've seen this solve an assortment of problems.

[PaulD1]

Good call MX

Adding the timestamp resolved the issues - thanks so much!

[Anonymous]

It's Magic I tell you 🙂

And good to know this worked !

[Anonymous]

I'm not sure that this problem has been fixed. I tried adding a timestamp data type column in the Azure table to fix this but it didnt work for me. 

Isnt this a bug that should be fixed? You should be able to show a read only primary key identity field in a edit form without it throwing an error when you save.

[tom_garvin]

It is not sufficient to have a Timestamp field in the Azure table, you also need to add it to the Edit Form.

I had the same issue with unreliable edits, even though my table already had a Timestamp field.

I've seen similar issues with application programs like Access, so as a habit, I include a Timestamp field on EVERY SQL Server table I design. The "cost" is insignificant. Purists will tell you the proper term is "rowversion", and this is because "timestamp" syntax has been deprecated, yet even in SQL Server Management Studio, only "timestamp" is accepted as a data type.

[duffysp]

If that's what you call a long shot im eager to see what you class as an accurate snipin'
Fixed my issue - thanks.