axapta - AX 2009 Import/Export via Administration vs table preservation for data refresh -

i'm sql guy, forgive me dumb question, or in wrong place.

my instructions data refresh production lower environments have me going ax client , backing 8 tables file via pointy-clicky mouse action:

• empltable
• sysuserprofiles
• sysuserinfo
• syscompanyuserinfo
• dirpartytable
• employeetypes
• usergrouplist
• userinfo

then, stop aos's , best -- use sql copy data out of 31 tables , safe place, database restore, copy data 31 tables safe place. start aos's, sync dictionaries, , import 8 tables via ax client (all pointy-clicky like).

i can sync command line. can preserve 31 tables via sql command line. can start , stop aos's in right order command line. can't ax export/import tables step , 3 environments pointy-clicky angers me.

question, finally: happens on export/import in client, if anything, wouldn't covered dealing 8 tables other 31? dict sync wouldn't fix? there way tell might do? there simple way in x++ code export/import? kind of have grasp on sysstartupcmd , how stuff happen ax32.exe -startupcmd , sql easier me, being native tongue.

thanks reading that!

the process described seems unusual update process, makes sense in contexts.

as stated in comment, preserving data lower environment. process described in comments updates existing records old data, while keeping new data. if wanted attempt via sql, need write upsert (as new records may created while existing records updated). looks tables related users in manner, process make sense if there different set of users production lower environment, not unusual, in sox regulated environment. data dictionary sync wouldn't in situation - updates table schema in sql match definition stored in ax. since schema hasn't changed, nothing happen.

with other (31) tables mention, sounds you're doing more of table replacement (so table truncated prior inserting new data, or data restore process otherwise discarded/ignored), why process may different 8 user tables.

in case, answer question directly, don't know of out-of-the-box process automate you. startupcmd= flag, logical place this, import command available xpo (code) files. if wanted automate process, need create new class extends sysstartupcmd , call same functions manually. wouldn't difficult, take little bit of research determine commands , parameters used. can @ sysstartupcmdaotimport class idea of how structured. import process seems controlled sysdataimport class, @ mimic user input or see process does.

if looking alternative (automated) process, consider when data update of our environments (we have environments update every day, update couple times month, others whenever feel it's needed, 100% automated), run sql script updates or creates necessary records after backup restored. values hard-coded script, since don't change it's not big deal. downside of technique compared yours, if have user needs access non-production environment, must first in production environment (disabled), , script updates necessary values next time target environment updated. additionally, system developers/administrators need sure communicate changes need made script (for example, if new table values need changed or new set of user permissions), adds overhead process.