I don't understand the question.
Access lock allows to read a table where an write lock is placed. The table is stored on disk or might be available in cache - where you have no controll about this.
Results of a read will be stored in spool.
My Question is when user A is inserting one record to table1, At that point of time if user B runs a select query to see all the records using ACCESS lock then where does the record inserted by user A exist.
When an insert is performed to a table on Teradata, the row(s) is inserted directly into its position in the table. There is no separate place where rows are stored while being inserted. Some processes that insert volumes of rows put them in temporary places first (INSERT SELECT, MERGE, Multiload acquisition phase, Fastload phase 1) but once the rows are being inserted into the target they are placed where they will stay.
This results in the behavior described by Ulrich above where if a scan is running and a row is inserted before the current scan position it will not be seen by the scan, but if it is inserted after the current scan position it will be included.
I do not like calling this dirty read because it will not be affected by operations such as block split, cylinder split,... There will not be missing rows while update or bulk DML operations are going on. More correct is to call Access Locks "Read Uncommitted" which means that the access lock reader may see things that are in the process of being inserted or updated even though that operation has not committed.
There is one exception - An update operation that updates the PI will be implemented internally as two separate steps: a delete for the old rows and an insert of the updated rows. During the interim, it is possible for there to be rows logically missing from the table. It is advisable to perform this type of opertion with an Exclusive lock to ensure access lock readers do not get unexpected results.