Solved Copy the Primary Key [ID] and Place It In a Different Control in Same Form

@GPGeorge , are you saying that my suggestion on how to link the child to the parent won't work, aside from potential table size issues?
I think you can work around the problem, yes. You can't avoid SharePoint's self-absorbed desire to control everything it sees, though.
 
Well you were right again.... using

If IsNull(Me.ID_Activity) and Not IsNull(Me.ID) Then
Me.ID_Activity = ID
End If

in the AfterUpdate, the form locked in the Edit mode. I guess to move past this issue I will just use the DMax and increment +1. We tried. I am interested in the Citrix and RD. I think the reason my clients like the Sharepoint is because they have the Office 365 Business which includes Sharepoint.... I doubt they will want to spend much money on another cloud-based solution unless its FREE. ha ha ha
Pat's remark on the limitations of SharePoint regarding record numbers is crucial to thinking about using SharePoint. Theoretically, SP lists can hold many thousands of records. In practice, the upper limit you can expect to use is going to be much less. If you have a relatively small, simple database application and never expect to exceed say 20,000 or 25,000 records in a table, SharePoint is a viable option. It's not a cut and dried number, though. YMMV.
 
Can't you define non-autonumber field as primary key in parent table? You can still have autonumber field in table but ignore it. I have designed dbs that do not use autonumber as primary key field. I use a vba generated unique identifier. DMax() is often used to increment a non-autonumber field.

The code you attempted should work once the ID is generated. So exactly when does that happen? I don't know how SharePoint impacts this but in normal Access, the autonumber is available in the BeforeUpdate event of any control that is edited on a new record. I just tested.
Not in SharePoint. You have zero control over this. The Primary Key is always created and it's always an Autonumber.

In fact, by using their own pseudo primary key, all that is happening is that the actual PK is being ignored.
 
@GPGeorge , are you saying that my suggestion on how to link the child to the parent won't work, aside from potential table size issues?
I re-read your post suggesting that. It sounds like the same method I blogged about 10 or 11 years ago when we had this shiny new toy called "Access Web Databases" :rolleyes:
 

Users who are viewing this thread

Back
Top Bottom