Форум: "Начинающим";
Текущий архив: 2010.10.03;
Скачать: [xml.tar.bz2];
ВнизКак пробежаться по строкам 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]
Красиво печатать из базы данных, а не из мемо, и проще.
← →
Anatoly Podgoretsky © (2010-07-05 12:21) [21]> azamatufa (05.07.2010 11:53:18) [18]
Не зарекайся, иначе придется вешаться, когда появится другая.
← →
Юрий Зотов © (2010-07-05 12:52) [22]Кстати, ИванИванычу никто не мешает сменить и фамилию, и даже имя. Вот тогда точно наступит капец, потому что для хранения истории изменений таблица не приспособлена.
← →
azamatufa © (2010-07-05 15:15) [23]
> Юрий Зотов
Хорошо, уважаемый Юрий! Раз Вы хотите меня направить на путь истинный, позволю себе проконсультироваться у Вас и, конечно же, у не менее уважаемого All"a ;)
"Кадровая (узкопрофильная) программа".
Есть 40 филиалов. В каждом работает по 100 человек.
Раз в полгода (или чаще) они должны "выгружать" мне свои данные.
Каждый человек может "двигаться":
- быть действующим работником
- просто состоять в кадровом резерве
- быть действующим + состоять в кадровом резерве
- действующий/резервист может быть назначенным на должность (+ снова зачислиться в резерв)
- быть исключен из кадрового резерва
Чтоб сделать все по уму, как Вы сказали, надо предусмотреть "версионность" записей (историю).. а это (пока кажется что) сложно.... (((
Я (пока) выбрал вариант, когда идет конкретный дубляж данных:
отдельная таблица действующих
отдельная таблица резервистов
и т.п.
Может Вы сделаете срез "моих" желаний и дадите ЦУ в каком направлении думать дальше.....
Спасибо!
← →
12 © (2010-07-05 15:21) [24]> Может Вы сделаете срез "моих" желаний и дадите ЦУ в каком
> направлении думать дальше.....
Я не ЮЗ, но если бы я был ЮЗ, я бы направил читать теорию разработки БД
← →
Anatoly Podgoretsky © (2010-07-05 15:33) [25]> azamatufa (05.07.2010 15:15:23) [23]
Это не сложно, достаточно добавить два поля - начало и конец действия
записи.
← →
Юрий Зотов © (2010-07-05 16:53) [26]> 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 тыс. баксов в месяц. Причем в то время он был еще Петровной, а не Иванычем.
=============
Вот примерно в таком направлении я бы и думал - все ли необходимые данные мною охвачены; какие из них нужно хранить с историей, а какие нет; нельзя ли в этой схеме что-то упростить - и т.д.
← →
azamatufa © (2010-07-06 09:26) [27]
> Юрий Зотов
Огромное спасибо за такой ответ!
Пару вопросов:
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. Еще раз спасибо за отличные идеи и мысли! Я обязательно это возьму на вооружение!
← →
Юрий Зотов © (2010-07-07 07:35) [28]
> 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. Получив его, все филиалы соответственно обновляют свои БД, а филиал-источник очищает ставшие ненужными записи в своем журнале изменений.
Примерно так. Сразу скажу - хотя все это и работало, но геморроя при разработке и последующем вылавливании ошибок было выше крыши, уж больно хитрой оказалась логика репликаций. Поэтому лучше всего сразу убедить заказчика в том, что игра не стоит свеч и нужно делать так, как делают все нормальные люди - единую БД с разграничением прав доступа. Наш заказчик тогда настоял на своем, было угроблено куча времени и денег - а спустя некоторое время он сам понял, что был неправ и что ему самому работать с такой БД крайне неудобно. Но поздно - все было уже сделано, внедрено и им оплачено.
← →
azamatufa © (2010-07-09 07:22) [29]Еще раз, спасибо за Ваш опыт!
Страницы: 1 вся ветка
Форум: "Начинающим";
Текущий архив: 2010.10.03;
Скачать: [xml.tar.bz2];
Память: 0.54 MB
Время: 0.004 c