В акцессе, как я понимаю, два типа текстовых - "МЕМО" и "текст".
У меня БД по данным о mp3-файлах (автор, название и пр.). Ключом в таблице должно быть имя файла - я не уверен, что ограничение в 255 символов, предлагаемое в поле типа "текст", тут уместно. Кроме того, акцесс соглашался индексировать по МЕМО %)
Вообще, хотелось бы все поля в таблице иметь длиннотекстовых типов (по крайней мере, без ощутимых ограничений) - varchar или text SQLевские подошли бы, но Акцесс с ними не владах...
Думаю вот о переходе на FB, но я слышал, что он начинает тормозить при кол-ве записей ~1000, хотя по поддержке SQL он богаче Акцесса, это уж точно.

pkarklinЭээ... MS SQL имеет тип данных varchar(n), где n от 1 до 8000. И их естественно стоит индексировать. Но вот стрить на нем PK... Я сторонник суррогатных ключей, а на имени файла в таком случаи вешается UNIQUE CONSTRAINT.

Хорошо. Пусть будет UC. Но если бы всё было так хорошо ) Мой VFP и это отказывается делать ) Ну чёрт с ним. Он у меня вообще случайно да и то 6й версии (бугагага), и возможности (и желания) обновлять нет.
pkarklinЕсли меня не подводит память, то Access вполне успешно работает с полями тип varchar или text.
Либо Вас подводит память, либо что-то подводит меня %)
Только что пробовал такие запросы:
ALTER TABLE db.Tags ADD TestCol1 varchar (1000) /*(1)*/
ALTER TABLE db.Tags ADD TestCol2 text /*(2)*/
ALTER TABLE db.Tags ADD TestCol3 text (1000) /*(3)*/
Результат:
(1) - ругается на слишком длинное поле
(2) - создаёт колонку типа "Текст" длиной в 255 символов
(3) - ругается на слишком длинное поле
Кроме того, в самом Акцессе (при редактировании таблицы) - ни слова о текстовых типах кроме "Текст" и "Поле МЕМО"

zloy_denПлакал.
Где эту глупость сказали?
Допустим глупость) Тогда хотелось бы услышать конструктивное предложение: решит ли FB вышеуказанные проблемы? Если нет, то что решит?
(предложенный вариант, естесственно, должен подходить под описанную ситуацию - бесплатная БД, которую можно без зазрений совести и физическиз трудностей таскать за программой)