How to copy data from one table or form to another in Access (1 Viewer)

[ZKHADI]

Hello friends

i am working on a database. there i have 3 tables
1. Student Data
2. Unpaid Fee
3. Paid Fee

i link them together by query one student have multiple times fee voucher fee print.
when i made voucher in unpaid fee table it is still unpaid condition which is not added in accounts means in paid fee table.
there i create a check box when the student paid the fee and handed over the voucher then i will check the box as paid.
now i want shift the unpaid fee to paid fee table / form. how i will do this.

the image is attached.

how i will code on checkbox on click event.
i wrote the code but it didnt work.

 

[June7]

Really shouldn't have to 'shift' data from one table to another. Have a field that flags record as "Paid". A date/time field would be best: DatePaid.

 

[ZKHADI]

but we can send same data to another table or form?

 

[The_Doc_Man]

I'm with June7 here. If you have a "Paid" checkbox on the form but also have a "DatePaid" then in the Form_Current routine, you can simply look at the DatePaid. Have a default value of the DatePaid routine of #31-Dec-9999# (which looks odd but is a valid date for Access). It is also a (very far) future date as in "not paid yet." In the Form_Current, you can use something like

Me.Paid = Me.DatePaid > Now()

 

[The_Doc_Man]

You can ALWAYS send data anywhere you want - but the question is SHOULD you?

When you study normalization, you would realize that if you have an UnpaidFee table and a PaidFee table, that violates normalization in that the records in the two tables would have the same structure (or so it seems to me) but the location of the record depends on a value that isn't the Prime Key. (In fact, not a key of any kind.) If you have a Fee table and a FIELD that shows date paid, you have everything you need but in one less table.

 

[Eugene-LS]

now i want shift the unpaid fee to paid fee table / form

Duplicating data in a database, and even in different tables, is a very bad practice.
It will be difficult for yourself to process this data .
I assume: your scheme of work is far from optimal.

 

[ZKHADI]

check below the below image ... in this image i have 2 tables Feetable and Paidfeetable.
first i will select the fee for student which is unpaid yet and print the fee voucher for student. when they pay and submit me the voucher. i will check the box and duplicate that data into Paidfeetable which i will get record for the deposited statement.

 

[June7]

We understand that is the process you have now and we are saying you should not. Unless you allow for partial payments, in which case you might want to consider form/subform arrangement.

 

[gemma-the-husky]

Just on another point, you don't need to copy data from one form to another, and should try to avoid copying or moving data. .

What you do is update a table that contains the data and then requery the form(s).

So if you have (1) a table of invoices, (2) a table of payments, and (3) a table matching invoices and payments - then you can write queries to show

all invoices
outstanding balances of invoices
unpaid invoices
and so on, by suitable queries

So if you have a payment, you use a form that manages the matching of the payment to particular invoices, and stores that matching result in table (3) above. (or something similar). This 3 table system allows for a payment matching to multiple invoices, and an invoice being paid in multiple instalments, which is the worst case, and therefore a generic solution for all payment matching problems. In big systems this process can be pretty complex. In many cases it's much more straightforward.

That's what all the above posts are suggesting.

 

[Pat Hartman]

If your table looks like the image, you have a bigger problem because you need to normalize your table schema. You have twelve fees. This is an Excel spreadsheet, NOT a relational table. The Fees need to be defined as ONE per row rather than 12 per row. Think about what you would need to change if you had to add a thirteenth fee -- forms, reports, queries, and code. If you properly normalize the table, all you need to do is to add one row to a table. No programming changes at all.