analysing bugs/run time problems

nadsys

Registered User.
Local time
Today, 01:47
Joined
Apr 22, 2005
Messages
18
hello all, two things, firstly, i would like to start my program and go through it step by step using the debugger. from that i can hopefully see what is going wrong and what my variables contain at each point throughout my program.

my problem is this:

under General of main form i have a variable declared as:

Public lngLastFocus As Long

then a small procedure in main section:

Code:
Private Sub WorkStationSoftwareOpen_Click()
   DoCmd.OpenForm "frmIMBUIPAddresses", acNormal, "", "", acEdit, acWindowNormal
   lngLastFocus = Me.CurrentRecord
      
If lngLastFocus <> 0 Then
DoCmd.GoToRecord , , acGoTo, lngLastFocus
End If
   DoCmd.Close acForm, Me.Name
End Sub

so on the click of the button on main form it should go to the current record they have selected. this only works if its record 1, if they choose record 2 or 3 etc then it crash's with runtime error 2105.

if i debug, the value in acGoTo = 4, the value in lngLastFocus = (the number of the record i was looking at(which is correct)). so what can i do to make this acgoto thing behave like it should, why is it pointing at number 4? i really am baffled.

thank you for any help. i have attached program for you guys to have a look if you would be so kind.

(program does as it should for "workstation ip address" button, yet not for any others, same code. relationships same too (i think)).
 

Attachments

The database is certainly not normalised and I can't see what most of it is meant to be. You really need to think about what it is you are wanting to store and how it should actually be stored.

Also, you are using the CurrentRecord property of the form's recordset. This is only the number of the record and, since your forms are bound to tables, there is no order to the recordsets meaning that the CurrentRecord between forms is not always going to match.

I've changed the code on the form a little bit, however, to save duplication of code. Other than that, it needs normalised (or else suffer ongoing problems) before you even think about making forms, queries, reports, etc.
 

Attachments

thank you for fast response

i have since posting talked to a work mate. i have found a way of doing it with current design. its ugly but works. As it needs to be running ASAP i am going to deliver it as is, then go back and change complete structure to how it should be. i've noticed so many faults in design. (its not my proj, its for a mate who i took it off and fixed up, i would have started by paperwork if it was me(honest))

been out of education for 5 years and forgotten all my db design and programming, only just starting to remember it. i like your coding alterations, reducing duplication, in my defense i only did it for speed.

ok, SO, maybe you can help me clarify how it should be, this is my plan.

The first forms 6 fields are unique to each machine, therefore they should be in one table identified by an ID field set as the PK.

It should be done in subforms, rather than seperate forms.

the records i reference should not be by current record, but by currect ID of selected record.

my logic correct? anything you care to add?
 
nadsys said:
ok, SO, maybe you can help me clarify how it should be, this is my plan.

The first forms 6 fields are unique to each machine, therefore they should be in one table identified by an ID field set as the PK.

It should be done in subforms, rather than seperate forms.

the records i reference should not be by current record, but by currect ID of selected record.

my logic correct? anything you care to add?

Can you talk me through each table, what they are meant to be, etc ? It seems that there are things that belong in one table while there are other things (locations, orders, etc.) that need their own database. Attributes of things, also, require tables.

I don't know what PSS is an acronym of but it certainly wouldn't be the primary key of three tables.
 
there is a single box(PSS) containing two machines, pc1 + pc2. both pc1 and pc2 has its own information relating to it, such as IP address/software versions/catalog numbers.

the unique fields for the PSS are:
PSS ID (number given to single box, as above)
(pc1) Workstation name
(pc1) Workstation ESOC ID
(pc2) IMBU ESOC ID
(pc2) IMBU Serial Number
(pc2) IMBU CI Number

the design of the forms in current db are to be kept. The table structure is what needs to be improved and relationships clarified.

i broke the explanation above into english, pc1 in the db = imbu, pc2 = workstation.

how would you suggest i should improve the table structure and relationships, the PK fields also you said were wrong.
 

Users who are viewing this thread

Back
Top Bottom