opening_closing_calculations (1 Viewer)

vba_vaibha

New member
Local time
Today, 06:49
Joined
Apr 26, 2019
Messages
1
Attached herewith the screen shot of access query.
this table is having recordset of opening_wt, received_wt,used_wt and closing_wt.


I am trying to copy the 1st record from closing_wt recordset and paste it into the 2nd record position of opening_wt recordset -- so that it works like a ledger--


I am not a vba professional pls help me with full code.


thanks
 

Attachments

  • VirtualBox_WINDOWS XPSP3_26_04_2019_14_47_11.pdf
    36.8 KB · Views: 40

plog

Banishment Pending
Local time
Today, 08:49
Joined
May 11, 2011
Messages
11,638
Your method is incorrect and your database doesn't looked set up to do this correctly.

First, data doesn't get moved around in a database. You don't copy data hither and yon, you relate data and link it and then bring it together in a query. Second, you don't store calculated values. Opening_wt and Closing_wt sound like they can be logically deduced from other data in your database. If that's true, neither of those fields should exist in a table, but should be calculated in a query.

What you want is exentially a running total query (search the forum for that term). You use some records of a table to determine a total for another record of your table. However, do do that calculation (Opening of one day and closing of another) requires data that can be specifically ordered. You haven't given us a way to do that with your data.

You're data is ordered, but not grainularly enough. Why is the first record the first record? Why isn't the second record the first record? They both have the same date, so how do you specifically determine which of those 2 records is first? How is this data to be ordered specifically?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 08:49
Joined
Feb 28, 2001
Messages
27,131
To slightly expand on plog's comments, you should know this:

Access tables have no guaranteed or inherent or permanent order. They gain order through the actions of a query that contains some combinations of ORDER BY and GROUP BY syntax. The ordering by query is therefore based on data within a record.

If you do not have data with enough detail to provide a unique ordering of those records, then you will NOT have that unique ordering. Particularly when you are trying to update records, you open yourself up to causing changes in the ordering of the underlying table. Which means if you have multiple records with the same date (and no time portion), they might sort in one order today and, after an update, sort in a different order tomorrow.

If order is important to you, then you must ask what the order needs to be for your data in order to achieve your goal. Then you must include supporting data so that you can assert that order through a query. The good news is that whatever else you were trying to do CAN be done using queries rather than directly hitting the underlying table. Most of the things you will do want a RECORDSET - which can be obtained from a table OR a query, either one.
 

Users who are viewing this thread

Top Bottom