A Microsoft Office (Excel, Word) forum. OfficeFrustration

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.

Go Back   Home » OfficeFrustration forum » Microsoft Access » New Users
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Quick question



 
 
Thread Tools Display Modes
  #11  
Old April 20th, 2006, 06:31 PM posted to microsoft.public.access.gettingstarted
external usenet poster
 
Posts: n/a
Default 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  
Old April 20th, 2006, 06:33 PM posted to microsoft.public.access.gettingstarted
external usenet poster
 
Posts: n/a
Default 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  
Old April 20th, 2006, 06:39 PM posted to microsoft.public.access.gettingstarted
external usenet poster
 
Posts: n/a
Default 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  
Old April 20th, 2006, 06:48 PM posted to microsoft.public.access.gettingstarted
external usenet poster
 
Posts: n/a
Default 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  
Old April 20th, 2006, 06:55 PM posted to microsoft.public.access.gettingstarted
external usenet poster
 
Posts: n/a
Default 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  
Old April 20th, 2006, 07:21 PM posted to microsoft.public.access.gettingstarted
external usenet poster
 
Posts: n/a
Default 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  
Old April 20th, 2006, 07:29 PM posted to microsoft.public.access.gettingstarted
external usenet poster
 
Posts: n/a
Default 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  
Old April 20th, 2006, 07:42 PM posted to microsoft.public.access.gettingstarted
external usenet poster
 
Posts: n/a
Default 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  
Old April 20th, 2006, 08:39 PM posted to microsoft.public.access.gettingstarted
external usenet poster
 
Posts: n/a
Default 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  
Old April 20th, 2006, 08:44 PM posted to microsoft.public.access.gettingstarted
external usenet poster
 
Posts: n/a
Default 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump

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


All times are GMT +1. The time now is 02:16 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.