You major concern should be making sure that the referential integrity is intact when you do the import. You do not want rows in the dependant table to be pointing to rows of the parent table that do not exist in the parent table. THis can occur if you export from the parent table first, then export from the dependant table. Someone could have entered a new row into the parent table and a dependant row pointing to the new parent row before you started the dependant export. This would leave your parent export without the new row but your dependant export with the new row. One way to prevent this is to export the dependant table first and import the parent first (actually you should always import the parent first). This will prevent referential integrity breaks, but it will not prevent data consistency problems. You could end up with the parent rows, but not the dependant rows. How you handle this depends on how this affects you. If you can live with this scenario, and the next export/import will pick up the missing dependant rows and that is OK, then this is the solution. But if you need those rows, then you are going to have to do both exports in the same unit of work and prevent others from adding/modifying to either table during the unit of work. This is usually done by putting exclusive locks on both tables, then exporting.
HTH
Andy