ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Нужна помощь при добавлении данных в базу
36 сообщений из 36, показаны все 2 страниц
  все  
Нужна помощь при добавлении данных в базу
    #37101404
НадеждаМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
НадеждаМ
Участник
Есть база на MSSQL 2005, есть 3 оператора, которые в эту базу могут одновременно добавлять записи.
Вид:
идентификатор (napr_id),номер (number) дата(date), цель(purpose), Сумма(insbal), код оператора(kod_o), дата изменения(date_ch), Исключения(iskl)


Как сделать так, чтобы номера добавлялись под разными номерами (по порядку)?
Сейчас делаю вот так:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
IF  0  > sql_exec('Select (max(number)+1)as number from napr where YEAR(date)=YEAR(getdate()) ','pnum')  &&осн.запрос
					=messagebox ("Во время выполнения SQL запроса произошла ошибка!",  0  +  16  +  0 , _SCREEN.CAPTION)		
					RETURN 
				else
					.numbern.caption=alltrim(str(pnum))
				endif
	
				
				IF  0  > sql_exec('{call mn_getnapr;4(?pnum,?ppol,?plpu,?pdate_hosp,?ppur,?pdoctor,?pkod_o,?insbal,?iskl)}','pins')  &&осн.запрос			
					=messagebox("Во время выполнения SQL запроса произошла ошибка!",  0  +  16  +  0 , _SCREEN.CAPTION)	
					RETURN 
				else
					=messagebox("Добавление данных выполнено успешно.",  0  +  64  +  0 , _SCREEN.CAPTION)	
					.RELEASE	
				ENDIF
...
Рейтинг: 0 / 0
07.02.2011, 08:55
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37101522
прошелмимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
прошелмимо
Участник
В самой ХП считать макс.номер и обернуть все в транзакцию не?

Чаще всего в системах учета организуют так.наз.счетчики (диапазоны номеров)
через ссылку на доп.табличку-хранилище счетчиков(диапазонов).

пыс пыс: см.на стиль письма - ух жешь и жесть.
0 > - это шоб враг не догадался?
функция в ограничении - зло - это битвин должен быть.
приват перм-е - зло,
руками данные ворочать - зло - см. на курсорадаптер.
...
Рейтинг: 0 / 0
07.02.2011, 10:07
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37101587
НадеждаМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
НадеждаМ
Участник
прошелмимоВ самой ХП считать макс.номер и обернуть все в транзакцию не?

Чаще всего в системах учета организуют так.наз.счетчики (диапазоны номеров)
через ссылку на доп.табличку-хранилище счетчиков(диапазонов).

пыс пыс: см.на стиль письма - ух жешь и жесть.
0 > - это шоб враг не догадался?
функция в ограничении - зло - это битвин должен быть.
приват перм-е - зло,
руками данные ворочать - зло - см. на курсорадаптер.

По поводу "считать макс номер в ХП" была мысля. А как в транзакцию обернуть?

Про стиль письма....Я пока использую то что тут было до меня и менять это нет времени.
...
Рейтинг: 0 / 0
07.02.2011, 10:36
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37101605
прошелмимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
прошелмимо
Участник
НадеждаМПо поводу "считать макс номер в ХП" была мысля. А как в транзакцию обернуть?

читать тама

там-же читать про организацию счетчиков в доп.табличке

НадеждаМПро стиль письма....Я пока использую то что тут было до меня и менять это нет времени.


ну не знаю.

лучше день потерять - затем за 5 мин долететь. (С)
...
Рейтинг: 0 / 0
07.02.2011, 10:42
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37101647
НадеждаМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
НадеждаМ
Участник
прошелмимо,

Мне еще нужно перед добавлением записи в базу выводить номер следующего направления на форму, и соответственно у разных операторов они должны быть разные.
...
Рейтинг: 0 / 0
07.02.2011, 10:53
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37101696
прошелмимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
прошелмимо
Участник
НадеждаМпрошелмимо,

Мне еще нужно перед добавлением записи в базу выводить номер следующего направления на форму, и соответственно у разных операторов они должны быть разные.

делают наоборот.

как-то так:
при наборе(подготовке доекумента, или до опред.статуса док-та) номер не присваивают,
а присваивают в момент сохранения и
отображают сообщение об успешном сохранении документа
и "светят" присвоенный ему номер.
...
Рейтинг: 0 / 0
07.02.2011, 11:13
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37101718
Фотография Игорь Горбонос
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Игорь Горбонос
Участник
> Автор: прошелмимо
> делают наоборот.


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

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
07.02.2011, 11:22
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37101802
прошелмимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
прошелмимо
Участник
Игорь Горбонос> Автор: прошелмимо
> делают наоборот.


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




так, просто интересно:

занафега нужен "предполагаемый" номер в момент набивки несуществующего
(несохраненного) в БД документа?
...
Рейтинг: 0 / 0
07.02.2011, 11:47
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37101833
Фотография Игорь Горбонос
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Игорь Горбонос
Участник
> Автор: прошелмимо
> занафега нужен "предполагаемый" номер в момент набивки несуществующего
> (несохраненного) в БД документа?


Видимо нам, гусарам, не понять
Но мои пользователи тоже хотят видеть номер. А т.к. мне номеров не жалко, я и показываю :)

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
07.02.2011, 11:58
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37101850
прошелмимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
прошелмимо
Участник
Игорь Горбонос> Автор: прошелмимо
> занафега нужен "предполагаемый" номер в момент набивки несуществующего
> (несохраненного) в БД документа?


Видимо нам, гусарам, не понять
Но мои пользователи тоже хотят видеть номер. А т.к. мне номеров не жалко, я и показываю :)



если делать не так как нужно, а так как не жалко - можно убиться.

достаточно присвоения нового номера в момент сохранения
и тупо на пальцах объяснения логичности такового
тем кому нужно
...
Рейтинг: 0 / 0
07.02.2011, 12:04
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37101903
НадеждаМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
НадеждаМ
Участник
прошелмимо делают наоборот.

как-то так:
при наборе(подготовке документа, или до опред.статуса док-та) номер не присваивают,
а присваивают в момент сохранения и
отображают сообщение об успешном сохранении документа
и "светят" присвоенный ему номер.


В принципе я так и предполагала сделать, но диспетчера развизжались, а спорить с ними не хотелось. Придется принуждать...

[quot прошелмимо]Игорь Горбонос> Автор: прошелмимо
> делают наоборот.


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



Диапазон номеров не закреплен за операторами, так как они работают с клиентами и вводят не подряд. Приходит клиент, подходит к свободному оператору, тот вводит вводит и печатает новый документ.

прошелмимо
так, просто интересно:

занафега нужен "предполагаемый" номер в момент набивки несуществующего
(несохраненного) в БД документа? Номер нужен для того чтобы они по журналу сверялись
...
Рейтинг: 0 / 0
07.02.2011, 12:24
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37101922
Фотография Aleksey-K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aleksey-K
Участник
прошелмимоИгорь Горбонос> Автор: прошелмимо
> занафега нужен "предполагаемый" номер в момент набивки несуществующего
> (несохраненного) в БД документа?


Видимо нам, гусарам, не понять
Но мои пользователи тоже хотят видеть номер. А т.к. мне номеров не жалко, я и показываю :)



если делать не так как нужно, а так как не жалко - можно убиться.

достаточно присвоения нового номера в момент сохранения
и тупо на пальцах объяснения логичности такового
тем кому нужно
Присоединяюсь к [прошелмимо]!
Оставляя номер пустым, вы позволите серверу на основе дополнительной таблицы (с ее блокировкой перед выборкой сл. номер для предотвращения номеров-двойников) получить следующий номер документа. Введя свой номер, вы отменяете "автоприсвоение" номера. Какой номер получиться вы не знаете и поэтому показать его сможете только "ПОСЛЕ" выполнения процедуры на сервере.
С уважением, Алексей
P.S. Получения нового номера у меня оформлено в виде отдельной процедуры, которая может иметь возможность выделения номера с учетом дополнительных признаков документа (подразделение, типа документа, года документа и т.п.)
...
Рейтинг: 0 / 0
07.02.2011, 12:30
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37101981
Фотография Игорь Горбонос
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Игорь Горбонос
Участник
Надежда, а с каким журналом должны сверятся операторы? И как номера из журналов разделяются между операторами?


> Автор: Aleksey-K
> Автор: прошелмимо


Вы говорите правильно, но у каждого своя специфика. У меня номер - это как имя. Введено и используется только для
идентификации заявки, среди других. Причем эти номера, как и имена могут быть неуникальны. Так удобно пользователям.
Поэтому я и показываю номер _до_ того как он попал в базу. К тому-же этот номер меняется в процессе обработки заявки и
становится другим(тоже не уникальным).


Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
07.02.2011, 12:53
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102091
НадеждаМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
НадеждаМ
Участник
Игорь Горбонос,

У них есть журнал (один на всех 3-х), в который они записывают данные вводимые в базу (так на всякий случай). И если что...номера не совпадают, у них и у меня в базе, или что-то еще, то сразу звонят мне.
...
Рейтинг: 0 / 0
07.02.2011, 13:27
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102095
НадеждаМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
НадеждаМ
Участник
Номера никак не разделяются.
...
Рейтинг: 0 / 0
07.02.2011, 13:27
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102182
НадеждаМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
НадеждаМ
Участник
Игорь ГорбоносНадежда, а с каким журналом должны сверятся операторы? И как номера из журналов разделяются между операторами?


> Автор: Aleksey-K
> Автор: прошелмимо


Вы говорите правильно, но у каждого своя специфика. У меня номер - это как имя. Введено и используется только для
идентификации заявки, среди других. Причем эти номера, как и имена могут быть неуникальны. Так удобно пользователям.
Поэтому я и показываю номер _до_ того как он попал в базу. К тому-же этот номер меняется в процессе обработки заявки и
становится другим(тоже не уникальным).




У меня номер тоже как своего рода идентификатор записи, среди других. Он может быть не уникальным, но только в том случае, когда год записи, уже имеющей такой номер не совпадает с текущим годом.
...
Рейтинг: 0 / 0
07.02.2011, 14:10
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102198
Фотография Игорь Горбонос
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Игорь Горбонос
Участник
> Автор: НадеждаМ
> Номера никак не разделяются.


Какие-то требования к нумерации есть? Номера разных операторов могут быть одинаковы?

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

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
07.02.2011, 14:15
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102208
прошелмимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
прошелмимо
Участник
НадеждаМИгорь Горбонос,

У них есть журнал (один на всех 3-х), в который они записывают данные вводимые в базу (так на всякий случай). И если что...номера не совпадают, у них и у меня в базе, или что-то еще, то сразу звонят мне.

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

читать на тему:
"организация диапазонов номеров в еирпи системах" и т.д.

иначе, - сверять с журналом после сохранения.
реализуйте сохранение документа по алгоритму:
1. запустить транзакцию на сервере
2. присвоить номер
3. сохранить документ
4. если все ок - коммит
5. иначе - все откатить

все, - велосипеды придуманы
...
Рейтинг: 0 / 0
07.02.2011, 14:18
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102211
НадеждаМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
НадеждаМ
Участник
прошелмимо,

Ну журнал не мне выбрасывать, мне он и так нафиг не нужен :)
...
Рейтинг: 0 / 0
07.02.2011, 14:21
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102218
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВладимирМ
Участник
1. Насколько вероятна ситуация, что оператор создаст документ, некоторое время будет его редактировать, а потом удалит (или не сохранит) только что созданный документ?

2. Если оператор создал документ, но в процессе заполнения понял, что ошибся и удалил документ. Но пока он думал, другой оператор создал еще один документ. Т.е. имеем "дыру" в нумерации.

Следует ли номер документа, удаленный первым пользователем снова присвоить новому документу? Есть ли необходимость контролировать непрерывность нумерации?

3. Насколько я вижу, у Вас есть как идентификатор (napr_id), так и номер (number). Почему бы при создании нового документа не присваивать номеру значение идентификатора?

PS: формирование номера по принципу MAX()+1 - крайне порочная практика для многопользовательских приложений. По возможности, такой способ формирования номера следует избегать. Что, собственно, все и советуют, предлагая другие варианты решений.
...
Рейтинг: 0 / 0
07.02.2011, 14:24
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102226
прошелмимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
прошелмимо
Участник
Игорь Горбонос но у каждого своя специфика.


Игорь ГорбоносТак удобно пользователям.


гы...

пользователю вполне нормально и удобно увидеть создавшийся в системе документ
с присвоенным ему номером самой системой

новый номер и дает понять пользователю то, что в систему "упал" новый документ.
...
Рейтинг: 0 / 0
07.02.2011, 14:27
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102241
Фотография Игорь Горбонос
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Игорь Горбонос
Участник
> Автор: прошелмимо


Признаю, в моем случае можно и не показывать сразу этот номер, а показывать только после создания документа.

:)

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
07.02.2011, 14:39
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102243
прошелмимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
прошелмимо
Участник
ВладимирМ1. Насколько вероятна ситуация, что оператор создаст документ, некоторое время будет его редактировать, а потом удалит (или не сохранит) только что созданный документ?

2. Если оператор создал документ, но в процессе заполнения понял, что ошибся и удалил документ. Но пока он думал, другой оператор создал еще один документ. Т.е. имеем "дыру" в нумерации.

Следует ли номер документа, удаленный первым пользователем снова присвоить новому документу? Есть ли необходимость контролировать непрерывность нумерации?

3. Насколько я вижу, у Вас есть как идентификатор (napr_id), так и номер (number). Почему бы при создании нового документа не присваивать номеру значение идентификатора?

PS: формирование номера по принципу MAX()+1 - крайне порочная практика для многопользовательских приложений. По возможности, такой способ формирования номера следует избегать. Что, собственно, все и советуют, предлагая другие варианты решений.

пофлудю немнога

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

чета тама с журналами перемудрили.
может вначале поговорим о норм-ке, бух. политике и т.д.?

че там такое критичное, что пользователи боятся каких-то "дырок"?

в больших еирпи системах вполне нормальным считается
наличие сторнированных документов на которые пришлись какие-то номера и т.д.,
гы, а в некоторых случаях ручное передергивание счетчика диапазона
(зависит от организации учета и т.д....)

не, мне просто интересно, шо там за такой стратег. случай
с каким-то журналом с ручной писаниной.
(я к тому, что в курпных организ-ях
счетчик может быть организован и на одни сутки к примеру,
и в журналы руками никто ничего не пишет)
и какая ответственность в случае наличия "дырок", "дублей"...

гы, кстати описав выше алгоритм,
я от дублей Вас спас,
а вот от "дырок" от удаленных документов - нет
...
Рейтинг: 0 / 0
07.02.2011, 14:39
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102251
прошелмимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
прошелмимо
Участник
Игорь Горбонос> Автор: прошелмимо


Признаю, в моем случае можно и не показывать сразу этот номер, а показывать только после создания документа.

:)



окей, значит не стоит идти на поводу у пользователей.

вот, - я всегда делаю так как мне нужно

даже аналитиков и прочих стратегов заставляю писать тз апосля процесса разработки.
...
Рейтинг: 0 / 0
07.02.2011, 14:41
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102374
НадеждаМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
НадеждаМ
Участник
ВладимирМ1. Насколько вероятна ситуация, что оператор создаст документ, некоторое время будет его редактировать, а потом удалит (или не сохранит) только что созданный документ?

2. Если оператор создал документ, но в процессе заполнения понял, что ошибся и удалил документ. Но пока он думал, другой оператор создал еще один документ. Т.е. имеем "дыру" в нумерации.

Следует ли номер документа, удаленный первым пользователем снова присвоить новому документу? Есть ли необходимость контролировать непрерывность нумерации?

3. Насколько я вижу, у Вас есть как идентификатор (napr_id), так и номер (number). Почему бы при создании нового документа не присваивать номеру значение идентификатора?

PS: формирование номера по принципу MAX()+1 - крайне порочная практика для многопользовательских приложений. По возможности, такой способ формирования номера следует избегать. Что, собственно, все и советуют, предлагая другие варианты решений.

1 - вероятность есть, но это случается редко.
2 - непрерывность необходима
3 - с каждым новым годом номер документа должен начинаться с 1, потому значение napr_id не присваиваем значению number
...
Рейтинг: 0 / 0
07.02.2011, 15:24
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102410
Фотография Игорь Горбонос
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Игорь Горбонос
Участник
> Автор: НадеждаМ


Что мы должны Вас пытать? Вы можете изложить все требования к этим номера и их использование операторами?

Я правильно понял, что нумерация документов должна быть "бездырочной" и не зависить от вводящего оператора?


Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
07.02.2011, 15:34
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102421
Sergey Sizov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey Sizov
Участник
НадеждаМ2 - непрерывность необходимаДля чего? Зачем? Чем обусловлена необходимость? Вас это спрашивают.
Просто "так пользователи захотели" или таки есть какие-то более основательные причины?
Все говорят, что надо, но пока ни один заказчик не смог обосновать эту необходимость. Боюсь, что и в Вашем случае будет то же самое и кроме неопределенного "ну, надо" ничего более конкретного не будет.
...
Рейтинг: 0 / 0
07.02.2011, 15:36
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102444
Фотография Aleksey-K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Aleksey-K
Участник
Игорь Горбонос> Автор: НадеждаМ


Что мы должны Вас пытать? Вы можете изложить все требования к этим номера и их использование операторами?

Я правильно понял, что нумерация документов должна быть "бездырочной" и не зависить от вводящего оператора?



Если требуется непрерывность номеров, то тогда:
1. Редактирования номера документа пользователем должна быть запрещена!
2. Удаление документа не допустипо. Вместо этой операции должна быть в системе допустима операциия, выводящая документа из документаоборота ("аннулирование документа"). Т.е. документ в системе есть (и занимает номер), но имеет специальный статус "аннулирован" и не участвует нигде в операциях(удален и т.п.).
Другой вариант иметь таблицу удаленных номер и в процедуре выделение нового номера искать и в ней, но это не избавит вас от наличия пропущенных номеров на какой-то момент времени (удалили 3 документа, а добавили только 1).
С уважением, Алексей
...
Рейтинг: 0 / 0
07.02.2011, 15:48
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37102476
прошелмимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
прошелмимо
Участник
Sergey SizovНадеждаМ2 - непрерывность необходимаДля чего? Зачем? Чем обусловлена необходимость? Вас это спрашивают.
Просто "так пользователи захотели" или таки есть какие-то более основательные причины?
Все говорят, что надо, но пока ни один заказчик не смог обосновать эту необходимость. Боюсь, что и в Вашем случае будет то же самое и кроме неопределенного "ну, надо" ничего более конкретного не будет.

этой необходимости нет и в нормативке
(или я чего-то не знаю)

по поводу "дырок" проблему решает реализация "сторнирования документов" в системе,
а не просто удаление
т.е. при "правильной" организации процесса никто не мешает иметь в системе:
документ №2 - оформленный, утвержденный и выданный
документ №3 - оформленный, сторнированный по какой-либо причине и не выдававшийся никому
документ №4 - оформленный, утвержденный и выданный
....

при этом никто не мешает вести какие-либо журналы рег-и
исходящих документов, в которых будет регистрация:
100. ......
101. документ №2 от ...
102. документ №4 от ...
...

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

ну цен. бланки - это иное и не относится к тек.обсуждению,
но и там также имеется регламентированный способ учета и списания испорченных и т.д...
...
Рейтинг: 0 / 0
07.02.2011, 15:59
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37103196
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВладимирМ
Участник
НадеждаМ2 - непрерывность необходима
3 - с каждым новым годом номер документа должен начинаться с 1, потому значение napr_id не присваиваем значению number
Для поддержания непрерывности Вам потребуется таблица, содержащая "дыры" в нумерации. Это чтобы новый документ брал номера из этих дыр. Чтобы не заморачиваться с разделением функционала сначала на поиск "дыр", а потом на последовательную нумерацию можно сразу создать таблицу с максимально возможным количеством номеров за год.

Т.е., например, Вы знаете, что за год создется примерно 1`000 документов. Значит, создаете таблицу с 2`000 записей (нужен запас), где есть поле с порядковым номером. Кроме того, добавляется поле с признаком "Использовано"

Предположим, что эта таблица называется tabNum, код записи - это поле nextNum, а признак использования - поле isUsed. Тогда код определения ближайшей не использованной записи получается примерно такой

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
-- Табличная переменная, в которую будет записано найденное значение
DECLARE @MyTableVar table(nextNum int NOT NULL)    

-- Ставим признак "Использовано" на записи с минимальным кодом nextNum
-- и записываем в табличную переменную код измененной записи
UPDATE tabNum
SET isUsed =  1 
OUTPUT DELETED.nextNum INTO @MyTableVar
FROM tabNum t1
WHERE t1.isUsed =  0 
	and not exists(select  1  from tabNum t2 
			where t2.isUsed =  0 
				and t2.tabNum < t1.tabNum)

-- Возвращаем найденное значение
SELECT nextNum FROM @MyTableVar;

Разумеется, при удалении документа надо будет снять признак "Использовано" с соответсвтующей записи. Если необходимо, то добавьте поле с номером года и включите год в условие поиска.

Однако у такого подхода тот недостаток, что при большом количестве номеров он становится слишком не поворотлив. Долго рабтает, да и места много занимает.

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

Стандартное решение в данном случае - это таблица-счетчик. Примерно то, что Вам показали на foxClub. Т.е. никто не стремится использовать "дыры" в нумерации. Умерла, так умерла...
...
Рейтинг: 0 / 0
07.02.2011, 21:40
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37142524
BestiA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
BestiA
Участник
Sergey SizovНадеждаМ2 - непрерывность необходимаДля чего? Зачем? Чем обусловлена необходимость? Вас это спрашивают.
Просто "так пользователи захотели" или таки есть какие-то более основательные причины?
Все говорят, что надо, но пока ни один заказчик не смог обосновать эту необходимость. Боюсь, что и в Вашем случае будет то же самое и кроме неопределенного "ну, надо" ничего более конкретного не будет.

Непрерывности требуют для целей проверки. Допустим, что при проверке выясняется, что документы с номерами 133,134 есть, а следом за ними идёт документ 136. Возникает вопрос: "А где у нас документ с номером 135? Неужели вы такие, сякие нехорошие, удалили его из списка? К вам наверняка обращался клиент с этим документом... а вы тут следы заметаете... "
...
Рейтинг: 0 / 0
01.03.2011, 17:53
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37142596
Юристишко-выпускник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Юристишко-выпускник
Участник
BestiAНепрерывности требуют для целей проверки. Допустим, что при проверке выясняется, что документы с номерами 133,134 есть, а следом за ними идёт документ 136. Возникает вопрос: "А где у нас документ с номером 135? Неужели вы такие, сякие нехорошие, удалили его из списка? К вам наверняка обращался клиент с этим документом... а вы тут следы заметаете... "

кто проверяет?
...
Рейтинг: 0 / 0
01.03.2011, 18:16
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37143150
Фотография AndreTM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AndreTM
Участник
BestiAВозникает вопрос: "А где у нас документ с номером 135? Неужели вы такие, сякие нехорошие, удалили его из списка? К вам наверняка обращался клиент с этим документом... а вы тут следы заметаете... "
Это возможно только в случае, если имеется "твёрдая копия" с таким номером, с вашими реквизитами и с подписью некоего ответственного лица. Любые другие варианты просто не катят... И наличие отсутствия некоего "номера в последовательности" при условии, что аудит не выявил нарушения в движении документов и итогах оборотов - из разряда абстракций. Некомпетентность руководителей даже в пределах собственных полномочий и обязанностей, конечно-же, никто не отменял. НО! - это не ваши проблемы как разработчика. Поскольку вам никто не представил норматив, требующий непрерывной нумерации.

Где-то так примерно...
...
Рейтинг: 0 / 0
02.03.2011, 03:35
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37146792
BestiA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
BestiA
Участник
А что если применять следующий алгоритм:
Пишем хранимую процедуру:
1. получить максимальный номер документа в таблице на текущий момент и запомнить значение его автоинкрементного поля ID
2. Запомнить новый уникальный идентификатор. (NewID())
2. Вставить новую строку в таблицу попутно вставив в неё этот идентификатор.
3. Получить ID только что вставленной записи по значению идентификатора.
4. Вычислить новый номер как значение предыдущего + число вставленных между максимальной и новой записей + 1
5. записать вычисленный номер и вернуть его

Такая схема не спасёт от пропусков в нумерации, если документ удалить из середины, но при непрерывном заполнении она по идее должна нормально работать.

Хочу услышать мнения по этому поводу.
...
Рейтинг: 0 / 0
03.03.2011, 14:23
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37146852
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
НадеждаМпрошелмимо делают наоборот.

как-то так:
при наборе(подготовке документа, или до опред.статуса док-та) номер не присваивают,
а присваивают в момент сохранения и
отображают сообщение об успешном сохранении документа
и "светят" присвоенный ему номер.


В принципе я так и предполагала сделать, но диспетчера развизжались, а спорить с ними не хотелось. Придется принуждать...
НадеждаМ2 - непрерывность необходима
Если предложение выдавать номер постфактум не подходит, то можно предложить еще один вариант:
Сделать отдельную таблицу выданных номеров, где выданный номер закрепляется за оператором, оператору дается возможность создать документ с номером который уже за ним закреплен. Для повышения внимательности операторов издать внутренний указ "За взятый и неиспользованный номер в течении дня/недели/месяца штраф оператору 100р за каждый пропущенный номер, с вывешиванием фото оператора на доску позора"
...
Рейтинг: 0 / 0
03.03.2011, 14:40
| Ответить | Цитировать | Написать  
Нужна помощь при добавлении данных в базу
    #37146995
Юристишко-выпускник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Юристишко-выпускник
Участник
Dima TДля повышения внимательности операторов издать внутренний указ "За взятый и неиспользованный номер в течении дня/недели/месяца штраф оператору 100р за каждый пропущенный номер, с вывешиванием фото оператора на доску позора"

операторам обратиться в труд.инспекцию и прокуратуру
по факту грубого нарушения ТК РФ.
...
Рейтинг: 0 / 0
03.03.2011, 15:21
| Ответить | Цитировать | Написать  
36 сообщений из 36, показаны все 2 страниц
  все  
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Нужна помощь при добавлении данных в базу
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=41&tid=1584518]:
 0ms
get settings:
 9ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 46ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 58ms
get tp. blocked users:
 1ms
others: 13ms
total:  158ms
созд. / загр.: 158ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]