В принципе, ничего особо страшного не произошло в том смысле, что данные не потеряны. Просто нарушена взаимосвязь данных. А вот как это лечить, зависит от того, как именно исключенная таблица была связана с остальными данными.

1) ОБЯЗАТЕЛЬНО перед какими-либо попытками что-то где-то восстановить необходимо сделать резервную копию того, что собираешся восстанавливать. Просто чтобы не испортить все окончательно.

2) В простейшем случае все можно восстановить такими командами


Проблема в том, что такое добавление таблицу-то добавит, но не добавит много чего еще, что, теоретически, могло бы быть связано с этой таблицей. Если этого "много чего" не было, то этого хватит. А если было, то дальше ALTER TABLE или прямая правка в дизайнере таблиц.

-) Длинные имена полей: у свободной таблицы имя поля не может превышать 10 символов. При исключении из базы данных имена полей больше 10 символов автоматически "обрезаются". Точнее, теряют длинную расшифровку
-) Триггеры, правила, значения по умолчанию - это все внутри контейнера базы данных. У свободной таблицы - нет.
-) Триггеры таблиц, связанных с данной и ссылающихся на данную таблицу.
-) Индекс типа Primary при исключении таблицы из контейнера базы данных автоматически конвертируется в индекс типа Candidat. Хотя, на работоспособность программы это никак не повлияет.
-) Есть еще постоянные связи, но их восстанавливать не обязательно. На работу программы они никак не влияют.

Хотя, есть и "хакерские" трюки по восстановлению привязки таблицы к контейнеру базы данных.

Дело в том, что контейнер базы данных (файл DBC) - это обычная таблица, но с измененным расширением. Т.е. ее можно открыть как обычную таблицу

USE MyBase.dbc

Исключение из нее объекта - это всего-лишь удаление ряда записей. Но поскольку речь идет о таблице DBF, то под термином "удаление" понимается не физическое удаление, а установка метки на удаление. Т.е. все удаленные записи физически остались на месте, просто получили признак удаленной записи. Значит, достаточно просто восстановить все записи помеченные как удаленные командой RECALL.

Однако в самой исключенной таблице также есть ссылка на базу данных. Это просто имя файла контейнера базы данных с относительным путем доступа, записанное в заголовке файла DBF. За образец можно взять любую другую таблицу включенную в контейнер базы данных и посмотреть в каком месте (в каких байтах заголовка) записано имя контейнера. И скопировать это имя в то же самое место исключенной таблицы заменив пустые байты.

Но здесь надо работать как с файлами низкого уровня. Можно в каких-либо файловых менеджерах вроде Norton Commander, Total Commander, FAR и т.п. В блокноте (Notepad) такое делать нельзя!

Правда, даже такие хакерские трюки могут не восстановить кое-каких триггеров, если при проектировании базы данных использовался построитель Referntial Integrity, поскольку исключение таблицы, скорее всего, удалит и триггера в родительских/дочерних таблицах относительно удаленной. Но, в данном случае, под термином "удалит" надо понимать именно физическое удаление. Без какой-либо возможности восстановления.

Впрочем, возможно, при удалении будет создана резервная копия файла DCT - это мемо-поле контейнера базы данных, содержащая "тела" триггеров. Вероятно, это будет файл с тем же именем, но с расширением TBK. Хотя тут я не уверен.

Т.е. после такого "хакерского" восстановления надо бы еще сравнить с образцовой базой триггера связанных таблиц и вообще все хранимые процедуры.