How many records has the user selected to delete on a form?

[N2Life]

My form stores multiple records of payment against an invoice. TablePayment should always have at least 1 record for each invoice. This record has a field containing the InvoiceNumber, and other fields to be filled in at the time of a payment. User is able to delete payments in case of error.

Is there a way to know how many records the user has selected to delete on this form? I can then check to see if that equals the total number of payment records on file and can intervene with the BeforeDelConfirm event if user is about to delete all records.

I am using Access 2002.

 

[TheAceMan1]

How are ya N2Life . . .

I'd make a special form for this with a [blue]single-select listbox of invoices[/blue] and a synchronized [blue]munti-select listbox of payments[/blue]. The form allows you to validate automatically (via code) as necessary before finally deleting or canceling.

Special Note: [purple]Its a bad idea to allow users the power of deletion![/purple] . . . period! There's no telling what can be lost in this way! From the accidental to the vengeful and beyond, data is at great risk of being compromised. (I've been in court twice about this over the years).

Myself . . . I have a [blue]popup message that prompts users to contact adminstration[/blue] for this. Although it pisses them off its a small price to pay in maintaining your data. At the very least, [blue]a few key personnel on each watch assigned to this task[/blue] is better than the whole lot . . .

[blue]Your Thoughts? . . .[/blue]

See Ya! . . . . . .

 

[N2Life]

Thank you TheAceMan1,

I agree that allowing deletions can be risky, but this database is used by a very small company, with only 2 people entering payments.

I have found an alternate solution, using the form's AfterDelConfirm event. I count the number of records in the table of payments for the invoice number in question. If that count is now zero, I simply add back in 1 record. Problem solved.

The issue here was not the deletion of data per se. It was the deletion of ALL records for a given invoice number from one particular table.

 

[TheAceMan1]

N2Life . . .

Glad you found a solution.

However out curiosity (for my better unserstanding) you say:

[blue]TablePayment should always have at least 1 record for each invoice.[/blue]

Whats causing this to be necessary?

In realtime you send out an invoice and the customer then pays in some way (unless your working in reverse). If when you sit down the customer hasn't paid yet, how do you qualify a necessary payment that hasn't been made yet! (forgive my ignorance of your business).

See Ya! . . . . . .

 

[N2Life]

When the user creates the order for the goods going to the customer, a record is created in TableInvoice. At the same time, a record is created in TablePayment; the InvoiceNumber field ties this record to the record in TableInvoice. Ability to handle multiple payment records is needed because partial payments are made, adjustments must be made because of damaged goods, etc. The screen on which the user selects the invoice that will receive payment presents the invoice numbers based on records within TablePayment. You are absolutely right. This could have been handled differently, and if I were creating this database today, I probably would not create any record in TablePayment until the point at which a payment was actually ready to be made. But this simple approach has worked well with only a single problem over these several years. The fix I found should take care of even that possibility.

I find that with Access almost everything can be done by 2 different approaches, sometimes 3. One must remain a perpetual eager student so one can continually improve.

 

[TheAceMan1]

N2Life . . .

Thanks for the critique! Things did seem a little ambiguous as far as invoiceing & accounting are concerned . . .

[blue]You take care! . . . Ya Hear! . . .[/blue]

See Ya! . . . . . .