You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just putting this here as a note to myself. Last year I ran into an issue of copying runs outside of FRAM using the odbc and RODBC packages. This was due to the odbc package defaulting to batch the rows to be inserted or appended which isn't supported by MS Access.
A copy_run() function will potentially allow a run to be copied to the 2GB maximum size limit of the MS Access database, numbering in the 100's or 1000's of copies. Combined with mutating SQL statements (possibly wrapped in R functions?) this should make producing FRAM sensitivity analyses far more approachable with far less work.
Just putting this here as a note to myself. Last year I ran into an issue of copying runs outside of FRAM using the odbc and RODBC packages. This was due to the odbc package defaulting to batch the rows to be inserted or appended which isn't supported by MS Access.
r-dbi/odbc@ed2bf38#diff-8758296606bc29a0108076ef31b8a542d52d098b923b8007f94e28bbf7c2baaaR57 allows the number of rows being batched to be explicitly defined. Setting
batch_rows
to 1 ondbWriteTable()
ordbAppendTable()
will work against MS Access databases.A
copy_run()
function will potentially allow a run to be copied to the 2GB maximum size limit of the MS Access database, numbering in the 100's or 1000's of copies. Combined with mutating SQL statements (possibly wrapped in R functions?) this should make producing FRAM sensitivity analyses far more approachable with far less work.The text was updated successfully, but these errors were encountered: