A few possibilities that I see:

1) The ability to make modifications on the treeview may need to be hidden behind an edit button, and only allow 1 user to edit at a time.

2) Another feasible option (but not too user friendly) is to add & update a 'dirty buffer' field in your SQL 2000 table once a user begins to edit, so users will at least be aware that a conflict is occuring and they have the option of commit or rollback of their changes at that point. I've used apps that do this, and it's not the best option.

3) You COULD use triggers in some way here. You could create a new table to hold info on INSERTS, UPDATES and DELETES from the table that holds the data for the treeview. If you have a timer on your form periodically checking this table for updates, it can notify the user that changes have been made to the treeview and they need to refresh... or just force a refresh... or offer the option to ignore a refresh & stomp on the other changes.

4) The nodes must have unique keys. Are these key values stored in your table, or generated on the fly? If they're stored in the table, you can take advantage of this to update/add/delete only the nodes in question & not update the entire table which should greatly reduce your odds of conflict. Combine this idea w/ the ability to mark a 'dirty buffer' per node and then you can manage those conflicts if they do occur.

Options 2 and 3 are not really 'tight' in the sense that you still have the conflict of one person's changes being committed & not another persons. At least the user is aware of it though. Which option you go with will most likely come down to an operational question of how it needs to work, rather than what options are you bound to by the technologies available.