Copied from https://world.mendix.com/display/refguide3/Moving+from+2.5+to+3.0:
Important Change: Synchronization
In 3.0 significant improvements have been made in the way the Runtime synchronizes the domain model with the database containing user data. In short, it means that user data will be retained in more cases. However, there are some consequences that you have to be aware of.
Do not manually edit the database
In short, dropping a table entirely is a bad idea. You don't have to drop a table to delete or restore data anyway, you could just delete rows. Even manually deleting rows from a table could get you into trouble though, for example in the case of autonumbers that will maintain their value even if there are no rows.
Stuff like this should be handled by the Runtime server itself. I recommend importing the data in another way, such as with the database replication module.
just an idea;
Can you explain what prevents you from deleting and re-importing your data through a Mendix Microflow?
Very alternatively: did you consider deploying your app with that one entity (that your table depends on) deleted, which will delete your table. Then re-deploy with the entity again, you might export-import it to ensure the same config. That would, I guess, create a new blanc table. The next step would be to import your table from the last backup/restore point you have. I guess, if performance and context allows it, you can use a standard Mendix import or a batch procedure from the community commons?
Just an idea, might be a hell of a job if there are lots of dependencies...
I think truncate and insert commands are quite safe to reload your table, as they both make no structural changes. However, do note that your objects cannot have any associations or inheritance (incoming or outgoing), otherwise the unresolvable foreign keys will exists if you just truncate a single table. Data integrity can only be guaranteed if you do not alter the database directly but use Mendix