Excellent explanation. When adding record via code in an Access database, Access sets the AutoNumber value as soon as you "dirty" the record by setting any field value. That's why you can fetch the value before you save the record. In SQL Server, the database doesn't set the Identity value until you save the record, so you have to find it after the save and then grab the value.
John Viescas, Author
Microsoft Access 2010 Inside Out
Microsoft Access 2007 Inside Out
Microsoft Access 2003 Inside Out
Building Microsoft Access Applications
SQL Queries for Mere Mortals
(Paris, France)
On Mar 19, 2016, at 9:19 AM, yahoo@craven.de [MS_Access_Professionals] <MS_Access_Professionals@yahoogroups.com> wrote:
Did anyone explain to Adam why John's code is necessary and why it (usually) works?
With an Access backend, the DBEngine knows what's going on in the database because it "owns" it, Access assigns the Autoincrement values when you start to dirty a new record.
With a SQL Server Database (or other Back-ends) the DBEngine has no idea what is going on on the Database in the background. Some other process might be trying to pump data into the table and, while the user is busy filling out the details of the record to be added, neither Access Front-End and the SQL Server back-end know what the other one is doing. Adding a record to a SQL Table does not do anything to the back-end until it is saved so the record cannot be assigned an autoincrement value until it is actually saved, that is why the Autoincrement field remains NULL until after you save it. John's code alllows Access to *find* the record you saved and to return the values actually saved, including the Autoincrement field.
Again, Access does not know what is going to be saved in the back-end SQL Server table until it is saved. There are default values on fields which mean that the record actually saved might have some different values to those you sent in the update. There are calculated fields. There are triggers on SQL Server tables which might also mean that what gets saved in the record is different to what you saved in the update. That's where the dbSeeChanges comes in, it tells the DBEngine to go look for changes in the data in the backend and present them to the front-end.
Once you start to think about how different the connection to a SQL Server backend is compared to an Access file backend, you start to see how wonderful the magic is that the Microsoft people built into Access (specifically the Jet Engine and it's siblings.)
---In MS_Access_Professionals@yahoogroups.com, <JohnV@...> wrote :
Adam-
Did you try the DAO code in the article I sent you? Basically, you should be able to use the LastModified property to move back to the newly added record, then grab the Identity value:
Set Db = DBEngine(0)(0)
Set rst = Db.OpenRecordset("tblParentListBE", dbOpenDynaset, dbAppendOnly+dbSeeChanges)
rst.AddNew
rst![ParentName] = Me.ClientName
rst.Update
Set rst = Db.OpenRecordset("tblParentListBE", dbOpenDynaset, dbAppendOnly+dbSeeChanges)
rst.AddNew
rst![ParentName] = Me.ClientName
rst.Update
rst.BookMark = rst.LastModified
tID = rst!ParentID
rst.Close
Set rst = Nothing
rst.Close
Set rst = Nothing
John Viescas, Author
Microsoft Access 2010 Inside Out
Microsoft Access 2007 Inside Out
Microsoft Access 2003 Inside Out
Building Microsoft Access Applications
SQL Queries for Mere Mortals
(Paris, France)
On Mar 17, 2016, at 5:27 PM, runuphillracing@... [MS_Access_Professionals] <MS_Access_Professionals@yahoogroups.com> wrote:
---In MS_Access_Professionals@yahoogroups.com, <JohnV@...> wrote :This article might help:John Viescas, AuthorMicrosoft Access 2010 Inside OutMicrosoft Access 2007 Inside OutMicrosoft Access 2003 Inside OutBuilding Microsoft Access ApplicationsSQL Queries for Mere Mortals(Paris, France)On Mar 17, 2016, at 4:04 PM, runuphillracing@... [MS_Access_Professionals] <MS_Access_Professionals@yahoogroups.com> wrote:
---In MS_Access_Professionals@yahoogroups.com, <JohnV@...> wrote :Adam-Oh, I didn't notice that you were trying to capture the Identity value. There's a way to do that, but I don't remember. It *might* work if you move the tID = after the Update.Anyone else want to jump in?John Viescas, AuthorMicrosoft Access 2010 Inside OutMicrosoft Access 2007 Inside OutMicrosoft Access 2003 Inside OutBuilding Microsoft Access ApplicationsSQL Queries for Mere Mortals(Paris, France)On Mar 16, 2016, at 10:37 PM, runuphillracing@... [MS_Access_Professionals] <MS_Access_Professionals@yahoogroups.com> wrote:Adam
---In MS_Access_Professionals@yahoogroups.com, <JohnV@...> wrote :Adam-I don't see anything you need to change if you're using linked tables to SQL Server.John Viescas, AuthorMicrosoft Access 2010 Inside OutMicrosoft Access 2007 Inside OutMicrosoft Access 2003 Inside OutBuilding Microsoft Access ApplicationsSQL Queries for Mere Mortals(Paris, France)On Mar 16, 2016, at 8:43 PM, runuphillracing@...[MS_Access_Professionals] <MS_Access_Professionals@yahoogroups.com> wrote:
__._,_.___
Posted by: John Viescas <johnv@msn.com>
| Reply via web post | • | Reply to sender | • | Reply to group | • | Start a New Topic | • | Messages in this topic (10) |
.
__,_._,___
Tidak ada komentar:
Posting Komentar