Unbound Continuous Form?

[Carl Foster]

Hi, just a question as to whether this is possible.

I would like to create a data entry form where a user will be able to enter in multiple records into a continuous form which us unbound (So that the underlying table is not updated yet).

Then, once he has checked the data and perhaps performed some calculations on it, he then clicks "Save" button and ADO inserts the data into the table.

Now, is this possible and if so, how would I go about setting up the form to accept multiple entry?

Thanks

 

[virgosam20]

not sure i completely understand, bt here's a suggestion you could try...
have you tried changing your single form to a continuous one?

 

[missinglinq]

He never said anything about a single form! He stated that he wanted a continuous form!

I think the only way you can do this is to actually have a bound form, but bound to a second table, one that will hold the data temporarily while you do whatever it is you want to do with the data. After you're finished with your data manipulation, you can then append the records from the second table into the first, permanent, table and dlete the records from the temp table, leaving its structure available to do the procedure again.

 

[virgosam20]

Yes, i know that, but i was trying to understand what they already have. whether they are currently working with a single form and want to change to a continuous one, or whether they already have set it to be continuous. need to know where to start from. that was all.

 

[Carl Foster]

virgosam20: I have set the form to "continuous form", but when it is unbound, and the controls are unbound, I can't get it to "multiply the controls.

missinglinq Hmmm, that's an interesting idea. Does that mean that the information would have to be deleted out of the "temporary" table every time the data is saved in the proper table, or would I just let the information stay in there and grow and grow?

 

[Fernando]

Hi Carl, why dont you use a bounded form? It would be really interesting to know why.

 

[missinglinq]

After appending the records to the "permanent" table, Carl, you'd want to delete the records from the "temp" table, making it ready for the next data entry session.

Linq ;0)>

 

[Carl Foster]

Hi Carl, why dont you use a bounded form? It would be really interesting to know why.

Well, the form is going to be for making purchase orders. The user will need to enter in all the materials to be ordered and see a total, and then be able to compare that with ordering from another supplier to get the best deal, so I didn't want it saved to the underlying orders table until all the details were decided on.

Just another thought on this. I know in VB using ADO and Dataset objects you can do this kind of thing, create a dataset, enter info into it and then save to the database. Can this be done in Access? I mean, they are supposed to be introducing more support for ADO into it. If not, then I might just have to go with your idea missinglinq.

 

[Fernando]

I think ive done something like this. I also made a PO db that had a function to see what supplier will be the cheapeast to buy the whole order.

But for this the user had to create the purchase Order and enter all the items with some supplier, then press this button that will tell him if that supplier the price is cheaper than with other. If so the user will just change the Supplier since it was a Form (Query Purchase Table with Supplier Bounded) and a subform with the details of the order) so when he changed the supplier on the Form, it will change the details for that supplier updating the created record. To do this i needed a Item table and a Price table to store the supplier and item IDs to have a price.

 

[RoyVidar]

I think missinglinq suggestion is probably the best.

If bloat on your front end might be an issue, I'd suggest that your temp table(s) reside in a local temp db, which you can compact at regaler intervals.

The ADO approach.
If you create a disconnected recordset, you can't bind it to a form (that's not entirely true, you can bind it, and you can even have it display more than one record, but the controls will either contain nothing, or #error or something - it's been a while since I tested, so I don't recall the details). Should you need to run it even on the 2000 version, then forms bound to regular ADO recordset based on Jet data isn't updateable at all

I think perhaps if you use some third party control (Flexgrid?), you might be able to do that. Controls in other environments allow much more flexible control over the behaviour, while Access does a lot of stuff behind the scenes. From what I've read, the continuous form uses a metadata from the recordset/recordsource, which is based on/provided by the provider, which isn't available, or can't be set programmatic when you create a recordset.

There is another "kludge" that I sometimes find worthwhile, for records with few columns. I'll use a regular listbox to display records, then I have unbound controls (textboxes, combos...) above it where I can manipulate info, then add it to the list with a button. I'll chose which record to edit by selecting it and hit an edit button (or doubleclick), which will enter the information in the aforementioned unbound controls. For this, I could use a temp table, or just rely on what the list rowsource can hold. Due to formatting etc, the usability of this kludge has some limitations (understatement).

 

[Carl Foster]

Thanks guys for your help with this. I'll try out a few things and see what turns out best.