Редактирование DBF файла

@Чёрный Медведь · Регистрация: 31.12.2009

Author24 — интернет-сервис помощи студентам

Доброго времени суток, коллеги.
Изучаю C# и ADO.NET в частности. Работаю с DBF файлами посредством нетипизированных DataSet'ов.
Собственно, вопрос: как организовать возможность править любой DBF файл, структура которого заранее неизвестна?
Т.е. dataAdaper.SelectCommand очевидно какой-то такой

SQL

1	SELECT * FROM TABLE1

А вот как выглядит, например, dataAdaper.UpdateCommand для произвольного DBF ума не приложу. Подскажите, пожалуйста.

Заранее, благодарен.

@Winsor · 15.06.2011, 12:20

Если при добавлении в датасет Вы будете использовать CommandBuilder - то UpdateCommand,DeleteCommand,InsertCommand будут генерироваться автоматически на основании SelectCommand.например так

C#

this.VocabDataSet = new DataSet();
                OleDbDataAdapter da = new OleDbDataAdapter();
                da.SelectCommand = new OleDbCommand(String.Format("select * from {0}", TableName), this.Connection);
                OleDbCommandBuilder cd = new OleDbCommandBuilder(da);
                da.Fill(this.VocabDataSet, TableName);

Дальше делаете вызов

C#

1	da.Update(VocabDataSet, TableName);

И все работает.

@Чёрный Медведь · 15.06.2011, 12:36 **[ТС]**

Сообщение от Winsor

И все работает.

Спасибо за отзыв, я так и пробовал, но не работает, т.к. в DBF-ке нет PrimeryKey. А без него вылетает с ошибкой Dynamic SQL generation for the UpdateCommand is not supported against a SelectCommand that does not return any key column information

Пробовал так же делать так:

C#

1	table.PrimaryKey = new DataColumn[] { table.Columns["F1"], table.Columns["F2"] };

Не знаю насколько это правильно, просто пришло в голову попробовать. Ничего не изменилось, всё таже ошибка.

P.S.: Редактирование произвольного DataSet'а в C# - нетривиальная задача?

@Winsor · 15.06.2011, 12:45

Нет. задача обычная. просто должен быть праймари кей. Иначе как узнать, какую запись обновлять. Если нет возможности добавить - создавайте UpdateCommand руками... С динамическим созданием праймари кея не колупался, надо пробовать.

@Чёрный Медведь · 15.06.2011, 12:58 **[ТС]**

Возможности нет, т.к. DBF-ка создаётся и используется сторонней DOS программой и будет меняться со временем.
Честно говоря, я в лёгком недоумении, т.к генерировать руками Update запрос это очень трудоёмко для такой простой задачи. Велосипед какой-то получется. На тех же старых добрых Дельфях всё решается намного проще.

Кстати, о Primery Key. По логике он есть. Это 2 поля, которые я указал выше F1 и F2. Но во-первых, как указать DataTable'у, что это именно они, а во-вторых мне нужно update'ить именно их, а все остальные поля очищать.

Т.е. задача всё-таки нетривиальная? Подскажите, куда копать, народ!

@Winsor · 15.06.2011, 12:59

Терпение... Изучаю вопрос

@Чёрный Медведь · 15.06.2011, 13:45 **[ТС]**

Очень жду результатов

Т.е. изначально всё можно было бы решить одним запросом типа

SQL

UPDATE TABLE1
   SET F1 = 0,
       F2 = -1 -- так нужно по условию задачи
       F3 = NULL
       ...
       F55 = NULL
 WHERE F2 = ? -- какое-то значение

если бы структура файла не изменялась со временем

@Winsor · 15.06.2011, 14:24

Ну. Поковырялся.
1) Можно обойти, попробовав переопределить у CommandBuilder-а метод GetSchemaTable, куда добавлять инфу о праймари кее, потому что этот метод возвращает схему на основании SelectCommand, а в нем о праймари кее ничего не известно. Вы добавляете праймари кей в структуру DataTable, а не в "select * from table".
2) Написать свой генератор SqlCommand для DataAdapter, что кстати, не так трудно как кажется. Но при этом возникает вопрос - как гарантировать в физической таблице без уникального ключа что where по всем колумнам вернет только одну запись??? Порядок записей в физической таблице может не совпадать с порядком записей в датасете, можно конечно опираться на индекс записи... Но это неправильно. Можно понадеяться на авось, что where по всем колумнам вернет одну запись. Так что тоже не лучший путь.
3) таки добавить праймари кей.

Досовская программа как то же обновляет данные, какое-то поле она считает уникальным. Попробуйте сделать его ключом. Главное , чтобы оно было в select * from - тогда билдер сможет нормально обновлять данные.

@Чёрный Медведь · 15.06.2011, 14:41 **[ТС]**

Во-о-от. Это уже очень ценно! Ещё раз спасибо за потраченное время.

1-ый и 2-ой вариант считаю всё-таки трудоёмким (но реализуемым) для такого простого случая как мой, а вот третий ближе к к жизни. Действительно, как я и говорил выше, ключом логически считается поле F2, но как его сделать?

@Winsor · 15.06.2011, 15:51

Имелось в виду - изменить поле в физической таблице... Долго копавшись в коде, пытаясь понять

- все таки проще, если нету в физической таблице поля с типом Праймарикей - руками генерировать UpdateCommand.... Если кто найдет решение - сообщите

Добавлено через 52 секунды

C#

1 2	ds.Tables[0].PrimaryKey = new DataColumn[] { ds.Tables[0].Columns[0] }; ds.Tables[0].Columns[0].Unique = true;

Проблему не решает...

@Чёрный Медведь · 15.06.2011, 15:57 **[ТС]**

Да, так тоже пробовал. И не помогло... Очень жду совета бывалого мастера

@Winsor 334 / 270 / 18 Регистрация: 19.01.2011 Сообщений: 597
	15.06.2011, 12:45	4
	Нет. задача обычная. просто должен быть праймари кей. Иначе как узнать, какую запись обновлять. Если нет возможности добавить - создавайте UpdateCommand руками... С динамическим созданием праймари кея не колупался, надо пробовать. 1

@Чёрный Медведь 233 / 95 / 15 Регистрация: 31.12.2009 Сообщений: 224
	15.06.2011, 12:58 [ТС]	5
	Возможности нет, т.к. DBF-ка создаётся и используется сторонней DOS программой и будет меняться со временем. Честно говоря, я в лёгком недоумении, т.к генерировать руками Update запрос это очень трудоёмко для такой простой задачи. Велосипед какой-то получется. На тех же старых добрых Дельфях всё решается намного проще. Кстати, о Primery Key. По логике он есть. Это 2 поля, которые я указал выше F1 и F2. Но во-первых, как указать DataTable'у, что это именно они, а во-вторых мне нужно update'ить именно их, а все остальные поля очищать. Т.е. задача всё-таки нетривиальная? Подскажите, куда копать, народ! 0

@Winsor 334 / 270 / 18 Регистрация: 19.01.2011 Сообщений: 597
	15.06.2011, 12:59	6
	Терпение... Изучаю вопрос 0

@Winsor 334 / 270 / 18 Регистрация: 19.01.2011 Сообщений: 597
	15.06.2011, 14:24	8
	Ну. Поковырялся. 1) Можно обойти, попробовав переопределить у CommandBuilder-а метод GetSchemaTable, куда добавлять инфу о праймари кее, потому что этот метод возвращает схему на основании SelectCommand, а в нем о праймари кее ничего не известно. Вы добавляете праймари кей в структуру DataTable, а не в "select * from table". 2) Написать свой генератор SqlCommand для DataAdapter, что кстати, не так трудно как кажется. Но при этом возникает вопрос - как гарантировать в физической таблице без уникального ключа что where по всем колумнам вернет только одну запись??? Порядок записей в физической таблице может не совпадать с порядком записей в датасете, можно конечно опираться на индекс записи... Но это неправильно. Можно понадеяться на авось, что where по всем колумнам вернет одну запись. Так что тоже не лучший путь. 3) таки добавить праймари кей. Досовская программа как то же обновляет данные, какое-то поле она считает уникальным. Попробуйте сделать его ключом. Главное , чтобы оно было в select * from - тогда билдер сможет нормально обновлять данные. 1

@Чёрный Медведь 233 / 95 / 15 Регистрация: 31.12.2009 Сообщений: 224
	15.06.2011, 14:41 [ТС]	9
	Во-о-от. Это уже очень ценно! Ещё раз спасибо за потраченное время. 1-ый и 2-ой вариант считаю всё-таки трудоёмким (но реализуемым) для такого простого случая как мой, а вот третий ближе к к жизни. Действительно, как я и говорил выше, ключом логически считается поле F2, но как его сделать? 0

@Чёрный Медведь 233 / 95 / 15 Регистрация: 31.12.2009 Сообщений: 224
	15.06.2011, 15:57 [ТС]	11
	Да, так тоже пробовал. И не помогло... Очень жду совета бывалого мастера 0