Как пробежаться по строкам DBMemo?

← →
azamatufa © (2010-07-05 09:52) [0]

Есть FireBird, Delphi7, TIBDataSet в нем DBMemo поле.
Хочу в это Мемо содержать строки такого формата:
--------------------------------
2004-2005 | менеджер ООО Феникс
2005-2006 | складовщик ЗАО Пупкин
2006-2007 | зам.директора ОАО МММ
--------------------------------
т.е. трудовая деятельность человека, где "|" - разделитель.

Так, я должен писать и читать от туда.

Спасибо!

← →
И. Павел © (2010-07-05 10:08) [1]

for i := 0 to DBMemo1.Lines.Count - 1 do
Caption := Caption + Copy(DBMemo1.Lines[i], Pos("|", DBMemo1.Lines[i]) + 1, Length(DBMemo1.Lines[i]) - Pos("|", DBMemo1.Lines[i]));

Для более сложного разбора лучше использовать регулярные выражения.

← →
RWolf © (2010-07-05 10:11) [2]

> Как пробежаться по строкам DBMemo?

Наверно, так же, как и по строкам обычного TMemo, который является его предком.

← →
И. Павел © (2010-07-05 10:13) [3]

А если год всегда состоит из 4 цифр и число пробелов фиксировано, то:

for i := 0 to DBMemo1.Lines.Count - 1 do
begin
god1 := Copy(DBMemo1.Lines[0], 1, 4);
god2 := Copy(DBMemo1.Lines[0], 6, 9);
dolznost := Copy(DBMemo1.Lines[0], 13, Length(DBMemo1) - 12);
end;

← →
И. Павел © (2010-07-05 10:13) [4]

[0] -> [i]

← →
RWolf © (2010-07-05 10:14) [5]

> TMemo, который является его предком

TCustomMemo, если быть точным.

← →
Юрий Зотов © (2010-07-05 10:23) [6]

Читать - это просто, а вот как туда писать такие строки? DBMemo - он, вообще-то не для этого предназначен, насколько я понимаю.

Будет проще, если использовать обычный Memo. А еще проще - использовать DBGrid и не хотеть странного.

← →
Anatoly Podgoretsky © (2010-07-05 10:40) [7]

> azamatufa (05.07.2010 09:52:00) [0]

Писать через АДД, читать путем обращения к строке по индексу.

← →
azamatufa © (2010-07-05 10:43) [8]

Спасибо за ответы!

Юрий, просто не охота еще одну таблицу делать для этого... (это про "еще проще")

а с обычным мемо это как?

(а можно ли загнать данные из blob/memo-поля в TStrings напрямую, минуя (не создавая) компонент TDBMemo ? )

← →
Anatoly Podgoretsky © (2010-07-05 10:47) [9]

> azamatufa (05.07.2010 10:43:08) [8]

Конечно можно и нужно.

← →
azamatufa © (2010-07-05 10:50) [10]

> Anatoly Podgoretsky

а как? )))

← →
azamatufa © (2010-07-05 10:54) [11]

TStream?

← →
Anatoly Podgoretsky © (2010-07-05 11:00) [12]

> Anatoly Podgoretsky (05.07.2010 10:47:09) [9]

Не создавать DBMemo, а гнать потоком куда надо или превратить memo в string

← →
Юрий Зотов © (2010-07-05 11:10) [13]

> azamatufa © (05.07.10 10:43) [8]

> не охота еще одну таблицу делать для этого... (это про "еще проще")

А кто заставляет? Надо просто написать select, он соберет данные хоть из 100 разных таблиц - и не нужны никакие новые таблицы. А самый обычный DBGrig вполне успешно все это отобразит, без лишних телодвижений.

← →
azamatufa © (2010-07-05 11:10) [14]

Прошу прощения...

вот я считал так:
TrudMemo := TStream.Create; TrudMemo := DM.Uchet_Card.CreateBlobStream(DM.Uchet_Card.FieldByName("TRUD_DEYAT"),bmRead); TrudList := TStringList.Create; TrudList.LoadFromStream(TrudMemo);

а как бы теперь записать из TStrings в блоб (т.е. обратно)?

Спасибо!

← →
azamatufa © (2010-07-05 11:15) [15]

> Юрий Зотов

не уговаривайте)))
у меня по задумке одна табличка: Иванов,Иван,Иванович,муж,1962,место_работы,адрес,тел,трудовая_деятельность
"трудовая деятельность" - мог и просто TDBMemo, но хочу в последующем красиво печатать... поэтому и горожу огород....

← →
Юрий Зотов © (2010-07-05 11:19) [16]

> azamatufa © (05.07.10 11:15) [15]

И сколько же строк в этой таблице будет соответствовать ОДНОМУ И ТОМУ ЖЕ ИванИванычу? Он ведь адрес, телефон и место работы может хоть каждый день менять.

← →
Юрий Зотов © (2010-07-05 11:19) [17]

А для красивой печати существуют отчеты.

← →
azamatufa © (2010-07-05 11:53) [18]

> Юрий Зотов

Про нормальные формы я более менее слышал. В моем же случае тока одна запись про Иван Ивановича!

Гуру, подскажите как вогнать из TStrings в memo!

← →
12 © (2010-07-05 12:18) [19]

SS:tstrings;

begin
memo1.Lines.Text := SS.Text

← →
Anatoly Podgoretsky © (2010-07-05 12:20) [20]

> azamatufa (05.07.2010 11:15:15) [15]

Красиво печатать из базы данных, а не из мемо, и проще.

> azamatufa (05.07.2010 11:53:18) [18]

Не зарекайся, иначе придется вешаться, когда появится другая.

Кстати, ИванИванычу никто не мешает сменить и фамилию, и даже имя. Вот тогда точно наступит капец, потому что для хранения истории изменений таблица не приспособлена.

> Юрий Зотов

Хорошо, уважаемый Юрий! Раз Вы хотите меня направить на путь истинный, позволю себе проконсультироваться у Вас и, конечно же, у не менее уважаемого All"a ;)

"Кадровая (узкопрофильная) программа".
Есть 40 филиалов. В каждом работает по 100 человек.
Раз в полгода (или чаще) они должны "выгружать" мне свои данные.
Каждый человек может "двигаться":
- быть действующим работником
- просто состоять в кадровом резерве
- быть действующим + состоять в кадровом резерве
- действующий/резервист может быть назначенным на должность (+ снова зачислиться в резерв)
- быть исключен из кадрового резерва

Чтоб сделать все по уму, как Вы сказали, надо предусмотреть "версионность" записей (историю).. а это (пока кажется что) сложно.... (((

Я (пока) выбрал вариант, когда идет конкретный дубляж данных:
отдельная таблица действующих
отдельная таблица резервистов
и т.п.

Может Вы сделаете срез "моих" желаний и дадите ЦУ в каком направлении думать дальше.....

Спасибо!

> Может Вы сделаете срез "моих" желаний и дадите ЦУ в каком
> направлении думать дальше.....

Я не ЮЗ, но если бы я был ЮЗ, я бы направил читать теорию разработки БД

> azamatufa (05.07.2010 15:15:23) [23]

Это не сложно, достаточно добавить два поля - начало и конец действия
записи.

> azamatufa © (05.07.10 15:15) [23]

Во-первых, сразу же напрашивается отдельная таблица "Справочник филиалов" с полями ID (перв. ключ), Name (not null, unique) и любыми еще другими, какие нужны.

Вторая таблица - справочник должностей. Поля примерно те же - ID (перв. ключ), Name (not null, unique) и любые еще другие, какие нужны.

Третья таблица - справочник статусов (действующий, резервист, исключен и т.д.). Поля примерно те же.

Четвертая таблица - личные данные работников. Поля примерно такие:

ID (перв. ключ)
Prev_ID (ссылка на ID предыдущей записи в той же таблице; null означает, что эта запись первичная и предыдущей записи у нее нет)
Start_Date (дата начала действия записи, not null)
End_Date (дата окончания действия записи, null означает действующую)
Фамилия
Имя
Отчество
Пол
Дата рождения
и прочие редко изменяемые или совсем неизменяемые данные работников

Заметьте, что такая таблица может хранить не только текущие данные работника, но и всю историю их изменений. Например, она позволяет отследить, что нынешний Иван Иваныч пять лет назад сменил ФИО и пол, а до этого он был Марьей Петровной, а еще тремя годами раньше он был Верой Петровной.

Если нет отдельного справочника адресов (КЛАДР, например), то адрес нашего Иваныча тоже можно подстыковать в эту таблицу. После этого пусть он переезжает хоть каждый день - вся история его переездов тоже будет храниться. Как и смена номеров телефонов, если в эту же таблицу прицепить и телефон.

В общем, что хранить с историей, а что без нее - это решать Вам совместно с заказчиком.

Заметьте, что мы пока что ни слова не сказали о том, является ли наш Иваныч кадровым работником или резервистом, в каком филиале и на какой должности он работал, в какой период и и.п. Для этого мы сварганим еще одну, пятую таблицу - должностных перемещений. Примерно такую:

ID (перв. ключ)
Prev_ID (ссылка на ID предыдущей записи в той же таблице; null означает, что эта запись первичная и предыдущей записи у нее нет)
ID_филиала (ссылка на справочник филиалов)
ID_должности (ссылка на справочник должностей)
ID_статуса (ссылка на справочник статусов)
ID_работника (ссылка на первичную запись в таблице работников)
Start_Date (дата начала действия записи)
Номер_приказа_1 (на основании чего запись начала действовать)
End_Date (дата прекращения действия записи)
Номер_приказа_2 (на основании чего запись перестала действовать)
и т.п.

Заметьте, что эта таблица тоже хранит всю историю должностных перемещений - и наш Иваныч теперь как на ладони. Например, в любой момент мы можем определить, что в период с... по... он работал кладовщиком в филиале № 7 и получал 100 тыс. баксов в месяц. Причем в то время он был еще Петровной, а не Иванычем.

=============

Вот примерно в таком направлении я бы и думал - все ли необходимые данные мною охвачены; какие из них нужно хранить с историей, а какие нет; нельзя ли в этой схеме что-то упростить - и т.д.

> Юрий Зотов

Огромное спасибо за такой ответ!

Пару вопросов:

1. Вместо Prev_ID (который надо постоянно изменять) можно ведь постоянно тоскать с собой первоначальный ID (в поле Prev_ID) ? А хронологию по дате сечь...

ID Prev_ID Otchetstvo
1 1 Петровна
2 1 Николавна
3 1 Иванович (стал мужиком наконец) (End_Date - null)

2. В таблице должностных перемещений на какой ID_работника ссылаться? на первоначальный? или на последний актуальный..? (тоже вроде бы и так и так можно.. )

3. И еще больной вопрос: как правильно сливать данные от всех филиалов.. ведь ID"ы плывут... Мне кажется, надо в каждой таблице иметь поле Filial_ID...
и составной индекс Filial_ID + ID - например в таблица людей.

Спасибо!

p.s. Еще раз спасибо за отличные идеи и мысли! Я обязательно это возьму на вооружение!

> azamatufa © (06.07.10 09:26) [27]

Вопросы 1 и 2: непринципиально, как удобнее - так и делайте. Можно, например делать и так - вместо поля Prev_ID ввести поле "счетчик", а первичным ключом задать сочетание полей ID и Счетчик. Тогда получится что-то типа этого:
ID Счетчик Имя Отчество 1 0 Вера Петровна 1 1 Мария Петровна 1 2 Иван Иваныч
Тогда ID идентифицирует самого человека, а счетчик - номера относящихся к нему записей. Действующая запись имеет максимальное значение счетчика.

Вопрос 3: Вы сами на него уже ответили - ключ должен содержать ID филиала, тогда повторов не будет. Главное тут не это, а вот что.

Допустим, в филиале сделали запись в некую таблицу. Потом провели слив в центральную базу и там эта запись тоже появилась. Сразу возникают вопросы, требующие решения:

а). кто имеет право видеть эту запись (внесший филиал, центр, все филиалы и т.п.)?

б). в последнем случае - как обновить БД других филиалов (там же тоже эта запись должна появиться)?

в). кто имеет право изменять/удалять эту запись (внесший филиал, центр, все филиалы и т.п.)?

г). при модификации/удалении записи - как обновить БД других филиалов (там же тоже эта запись должна измениться/удалиться)?

===========================

Лет 5-6 назад довелось мне делать именно такую распределенную БД, и филиалов тоже было примерно как у Вас. Главной проблемой оказалась именно синхронизация БД (репликация) с учетом прав доступа - особенно, из-за того, что записи могли быть дочерними и родительскими. Например.

1. Филиал Ф1 внес родительскую запись РЗ и дочернюю к ней ДЗ. Дочерняя запись, естественно, ссылается на родительскую.

2. Филиал Ф2 должен видеть запись ДЗ, но ни при каких условиях не должен видеть записи РЗ. То есть, записи РЗ в БД филиала Ф2 просто не должно быть - и тогда в записи ДЗ в БД филиала Ф2 появляется битая ссылка. Нарушение ссылочной целостности, ни больше, ни меньше - и, тем не менее, все обязано работать.

Для решения в каждой БД был заведен журнал изменений (состоял из несколькких таблиц) и написан специальный модуль репликаций. В журнале каждого филиала фиксируются все изменения, сделанные филиалом в его БД, затем эти изменения выгружаются на диск в виде XML. Этот XML проигрывается в центральную БД и формируется другой XML. Получив его, все филиалы соответственно обновляют свои БД, а филиал-источник очищает ставшие ненужными записи в своем журнале изменений.

Примерно так. Сразу скажу - хотя все это и работало, но геморроя при разработке и последующем вылавливании ошибок было выше крыши, уж больно хитрой оказалась логика репликаций. Поэтому лучше всего сразу убедить заказчика в том, что игра не стоит свеч и нужно делать так, как делают все нормальные люди - единую БД с разграничением прав доступа. Наш заказчик тогда настоял на своем, было угроблено куча времени и денег - а спустя некоторое время он сам понял, что был неправ и что ему самому работать с такой БД крайне неудобно. Но поздно - все было уже сделано, внедрено и им оплачено.

Еще раз, спасибо за Ваш опыт!

Как пробежаться по строкам DBMemo? Найти похожие ветки