Issues with Bulk Replication of Data
We have a use-case where we would like to freeze a snapshot of month-end Inventory levels in a table that is a "clone" of our already existing Perpetual Inventory table. In my mind, it's so easy lol...
Forum Discussion
Oh yes...there are a lot of formula fields in there. Do you know if there are limitations around fields that are references/lookups from other tables as well? Upon further review that seems to be the case.
I'm newer to QB, so when you say convert it to scalar/entry, what is best practice for that?
Appreciate the reply!
------------------------------
Dave Brian
------------------------------
Since you're doing a true snapshot - you just want to convert them all to be entry fields so that nothing can change. So if in your original table the field was formula-numeric - you want to change the type to just be 'Numeric'. Do that across the board for any field that is a formula, summary field, lookup etc. The idea is that in your new table you won't have the same relationships or data feeds, so you're just storing all that data in a way that it can never change this way.
------------------------------
Chayce Duncan
------------------------------
ahhh - that makes sense! I'll give that a shot and see how it goes. Gonna be awhile given the number of fields in this clone.
------------------------------
Dave Brian
------------------------------Honestly it might be easier to scrap the current table - do an export of your current primary table and just do a simple import of records to a new table. In the way you could make a new empty table, import a file with all of your fields and some sample data and create all of your fields as numeric/text/date etc instead of going one by one and changing them all individually. Might save you some time.
------------------------------
Chayce Duncan
------------------------------Appreciate the tip - I actually ended up paring back the columns needed in the new table significantly so it wasn't too bad.
One more note on this for anyone else that views this thread and has a similar use case...I ended up creating a 'Key' field on the new table that corresponded to a concatenation of 'Book-Date' (i.e. Year&Month) and SKU so there is one record per Book-Date/SKU. I had some reservations using 'Record ID' (the default Key field) since there could be a situation where the Record ID in the new table has a corresponding match in the source table. With the 'Book-Date/SKU' key field, there should never be "match" on the target table. Maybe I'm off-base with my assessment, but that's how I went about it.
------------------------------
Dave Brian
------------------------------