Current record (2000)

I'm wondering if there is a way to write and IF/Than statement that looks to see if the record is current?? IE...............If current then bla bla bla else bla bla bla.

I'm not sure how to write it or if it's possible.

I'm also wondering if there is a way to go to another set of code. IE using an IF/Than statement, If a criteria is or isn't met then go to................I'd like it to go to a cmd that I've already set on a form or to an event. Is that possible??

Re: Current record (2000)

Leesha,

It isn't clear what you're trying to do. If you are dealing with a form or a recordset, then the current record is the only one you can address anyhow, so there is no conditional test required. The only other possible conditions are EOF or BOF, which mean that the pointer is not on a record at all but it at either the end of a recordset (after the last record) or at the beginning (before the first record), or NewRecord, which means the pointer is on a record that has not yet been saved.

It is possible to call a routine that already exists but you don't use gotos. In fact, erase goto from your memory banks except for error handling. It is generally bad programming and will get you in trouble. If you have a routine behind a command button Click event, you can trigger it like this:

Call cmdCommandButton1_Click()

Something like that will execute the click event of the command button and then return to the next line of code in the current procedure.

Re: Current record (2000)

I'm trying to erase Goto from my brain, per Han's previous warnings but it was the only way I could think to describe what I was looking to do. I wasn't sure how to do the "call cmd". I'll try this.

The problem happens when the user states they don't wish to save the invoice, therefore it isn't saved but is undone (undo) in the before update event, therefore when the code says save record in the click event that an error message comes up stating that there is no current record.

Re: Current record (2000)

You have conflicting instructions in your events and you need to sort out what is reasonable. It is not reasonable for a user to cancel the save and then expect to print an invoice. That is at least partly a training issue. Then you have to decide what you want to happen if they do not follow instructions. Are there certain fields that must be filled in if the record can be saved? If so, then test for that value being there and for Me.Dirty before attempting to save. If the record has been undone, then that value will be null. In that case, warn the user and exit the routine instead fo trying to save the record.