If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
Quick question
ADO huh? I think I'm gonna have to look into that.
"Dennis" wrote: Personally, I use ADO to do my database work. While it doesn't take advantage of Access' automated abilities (gag), it allows me complete control, and I know EXACTLY what's happening... "One confused underwriter" wrote: Almost forgot, here's what the Add Click event looks like now: Private Sub cmdAdd_Click() On Error GoTo Err_cmdAdd_Click DoCmd.GoToRecord , , acNewRec **Do you know what's missing? |
#12
|
|||
|
|||
Quick question
That code will create a new blank record in your form. If you see any values
in the controls, the control has a Default Value property that is putting it in. The way Access works it that it will add the record with the data filled in on the form once you move off the record, that is move to the previous record, the next record, select another record, or close the form. You can also force the record to update using Me.Dirty = False. Can you describe what happens when you click this button now? "One confused underwriter" wrote: Almost forgot, here's what the Add Click event looks like now: Private Sub cmdAdd_Click() On Error GoTo Err_cmdAdd_Click DoCmd.GoToRecord , , acNewRec **Do you know what's missing? |
#13
|
|||
|
|||
Quick question
Here's a specific example from one of my forms. When a button is clicked, I
execute this code. It's pretty easy to read.... Set dbConn = CurrentProject.Connection Set recSet = New ADODB.Recordset recSet.CursorLocation = adUseServer recSet.CursorType = adOpenKeyset recSet.LockType = adLockOptimistic recSet.Open "[tblPCInfo]", dbConn, , , adCmdTable recSet.AddNew recSet!LabID = Me.fldLab recSet!PCAssetNum = Nz(Me.fldAssetNbr) recSet!TME = Nz(Me.fldTME) recSet!PCModel = Nz(Me.fldModel) recSet!BIOS_Level = Nz(Me.fldBIOS) recSet!IPAddress = Nz(Me.fldIP) recSet!StaticIP = Nz(Me.chkStatic) recSet!OperatingSystem = Nz(Me.fldPCOS.Column(1)) recSet!OS_Version = Nz(Me.fldOSversion) recSet!Comment = Nz(Me.fldComment) recSet.Update MsgBox "Record added successfully", vbInformation DBEngine.Idle dbRefreshCache recSet.Close Set recSet = Nothing dbConn.Close |
#14
|
|||
|
|||
Quick question
If you use bound forms, you don't have to deal with that at all.
Note that Microsoft chose to abandon ADO as the default for Access and went back to DAO "Dennis" wrote: Here's a specific example from one of my forms. When a button is clicked, I execute this code. It's pretty easy to read.... Set dbConn = CurrentProject.Connection Set recSet = New ADODB.Recordset recSet.CursorLocation = adUseServer recSet.CursorType = adOpenKeyset recSet.LockType = adLockOptimistic recSet.Open "[tblPCInfo]", dbConn, , , adCmdTable recSet.AddNew recSet!LabID = Me.fldLab recSet!PCAssetNum = Nz(Me.fldAssetNbr) recSet!TME = Nz(Me.fldTME) recSet!PCModel = Nz(Me.fldModel) recSet!BIOS_Level = Nz(Me.fldBIOS) recSet!IPAddress = Nz(Me.fldIP) recSet!StaticIP = Nz(Me.chkStatic) recSet!OperatingSystem = Nz(Me.fldPCOS.Column(1)) recSet!OS_Version = Nz(Me.fldOSversion) recSet!Comment = Nz(Me.fldComment) recSet.Update MsgBox "Record added successfully", vbInformation DBEngine.Idle dbRefreshCache recSet.Close Set recSet = Nothing dbConn.Close |
#15
|
|||
|
|||
Quick question
I don't use bound forms because of the complexities of the applications. I
execute a lot of behind-the-scenes processing, and need total control over what's happening. However, in the ADO vs DAO debate, I thought it was the other way around (which is why I've been employing ADO). I seem to have read several recent papers on that. However, I'd be more than happy to read anything you'd care to reference in this thread. Thanks! |
#16
|
|||
|
|||
Quick question
I'm not sure which version, Dennis. It may be 2003 or I may be confused. I
did a little research, but don't have time to track it down. I do know that in 2002 ADO was the default. In either case, it doesn't matter which you use. ADO has some abilities that DAO does not, but comes with a different set of headaches. As to your position on bound vs unbound forms. Four years ago, I would have agreed with you 100%. I have found, however, that if you really learn how to use bound forms, they will make your life easier. One of the advantages is bound forms are usually lighter. That is, a completely "Lite" form has no code at all. It therefore loads and executes more quickly. When you have an unbound form, you really don't have any better control than you do with a bound form. Trust me on this, Dennis, I have done it both ways with complex applications. You also have to have a lot of code in the form which degrades performance to some degree. One trick you can use regardless of whether you use bound or unbound forms it to keep as much code out of the form as possible by putting it in a standard form and only putting enough code in the form to call the procedures in the standard form. Unbound forms are okay, nothing wrong with them. We each have our own style. And this is one of the reasons this forum is here - to trade ideas and opinions. "Dennis" wrote: I don't use bound forms because of the complexities of the applications. I execute a lot of behind-the-scenes processing, and need total control over what's happening. However, in the ADO vs DAO debate, I thought it was the other way around (which is why I've been employing ADO). I seem to have read several recent papers on that. However, I'd be more than happy to read anything you'd care to reference in this thread. Thanks! |
#17
|
|||
|
|||
Quick question
Headaches?? I could tell you stories... ;^)
As to using unbound forms - I need to code for future support capability. NO ONE here knows much about Access (or databases for that matter) except me. So... if I use ADO and unbound forms, it's more clear to someone coming along later as to exactly what is going on. From a maintenance standpoint, it's the only way to go (in the case of my organization). Then you have the users, who don't have a CLUE what the standard navigation controls do. I find it's far easir for them to create buttons that say: ADD REC, DEL REC, UPDATE REC, etc. Those they can understand.... *sigh* |
#18
|
|||
|
|||
Quick question
I agree with you on the standard buttons. My users never see them. I also
use descriptive buttons and my own set of Nav buttons. Those, of course, are not bound objects. How I hande them is always name the command buttons exactly the same so in case I have to address them. Then I have code in a standard form I call modFormOperation that handles each situation. I try to avoid referencing the control itself. Here is an example of my Delete button routine. All it takes is entering the following in the Click Event property box of the command button: =DelCurrentRec(Me) Public Sub DelCurrentRec(ByRef frmSomeForm As Form) Dim rst As Recordset On Error GoTo DelCurrentRec_Error Application.Echo False With frmSomeForm Set rst = .RecordsetClone rst.Bookmark = .Bookmark If .Recordset.AbsolutePosition 0 Then .Recordset.MoveNext Else .Recordset.MovePrevious End If rst.Delete If .Recordset.AbsolutePosition 0 Then .Recordset.MovePrevious Else .Recordset.MoveNext End If End With DelCurrentRec_Exit: On Error Resume Next rst.Close Set rst = Nothing Application.Echo True Exit Sub DelCurrentRec_Error: MsgBox "Error " & Err.Number & " (" & Err.Description & _ ") in procedure DelCurrentRec of Module modFormOperations" GoTo DelCurrentRec_Exit End Sub If other things have to be done because of special circumstances in the code, I call it from the event code. "Dennis" wrote: Headaches?? I could tell you stories... ;^) As to using unbound forms - I need to code for future support capability. NO ONE here knows much about Access (or databases for that matter) except me. So... if I use ADO and unbound forms, it's more clear to someone coming along later as to exactly what is going on. From a maintenance standpoint, it's the only way to go (in the case of my organization). Then you have the users, who don't have a CLUE what the standard navigation controls do. I find it's far easir for them to create buttons that say: ADD REC, DEL REC, UPDATE REC, etc. Those they can understand.... *sigh* |
#19
|
|||
|
|||
Quick question
Nothing appears to happen when I press the button. If I press the button for
next record (a small arrow at the bottom of the screen) then it goes to a blank record. But pressing Add Record doesn't do anything. So I've gone over to a blank record, pressed Add Record, entered the data, pressed Save Record, gone to the next record and closed the form. And it didn't save. The code: Me.Dirty = False - Where do I enter this in? How does it force the record to update? |
#20
|
|||
|
|||
Quick question
I can save changes made to previous records and the changes are stored in the
main table, but no new records can be added. Now this brings me to my next question. The two other tables that a linked to the main table have keys that are numbers and not autonumbers, does that make a difference? Shouldn't the main table need the autonumber and then it should make the update to the two records that are linked to it? |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Quick Excel formula question before I go on holiday tomorrow! | Pheasant Plucker® | General Discussion | 2 | October 5th, 2005 06:34 PM |
Have a quick question about borders and images help please | joedrifter1 | New Users | 2 | September 9th, 2005 09:41 PM |
Quick Little Formula Question | Naoki | General Discussion | 7 | August 16th, 2004 07:39 PM |
Quick question | General Discussions | 1 | August 5th, 2004 05:14 PM | |
quick question about PivotTables | Dominique Feteau | Worksheet Functions | 1 | June 14th, 2004 09:55 PM |