| Регистрация Правила Главная форума Поиск |
| 0
- 04.02.2013 - 18:56
|
Дано: База дбф, драйвер VFP OLE DB. Нужно из приложения на Visual Basic записать новый элемент справочника. Метод подключения через OLE не устраивает (медленно и избыточно). В принципе все понятно кроме одного: как самостоятельно сгенерировать новый ID справочника. Кто нибудь может подсказать ?
    | |
| 1
- 04.02.2013 - 19:10
|
Не днлай этого. Не надо. | |
| 2
- 04.02.2013 - 19:13
|
не слушай. разрешаю. только купи сначала мыло и веревку качественную - меньше потом мучаться будешь | |
| 3
- 04.02.2013 - 19:33
|
(1), (2) . Аргументы ? Страх нарушить структуру БД ? Справочник - один. По сути это лог входящих звонков с сервера IP телефонии. Он нигде не будет ссылкой, поэтому повреждение его не ударит по базе. Нарушение ID внутри него как я понимаю тоже ударит только по нему. Но появиться он должен в момент входящего рингтона, тут скорость важна, поэтому OlE- подключение и выгрузку загрузку не очень хотелось бы использовать. Как я понимаю, речь идет о изменении 2 таблиц - таблицы самого справочника и таблицы 1SUIDCTL. | |
| 4
- 04.02.2013 - 19:41
|  | |
| 5
- 04.02.2013 - 19:42
|
3-Aristo_big > Раз не понимаешь - делать нельзя. Будешь понимать - поймешь, почему нельзя. Рассуждения (3) неверны. Выводы неверны. Метод решения - тоже. | |
| 6
- 04.02.2013 - 20:17
|
(5) Я не против того, чтобы перечислили правильные методы. Кроме того, сам сделаю несколькими, потестирую, какие проблемы. Я же не собираюсь решение запускать сразу. Однако сейчас только пишете "делаешь плохо", с загадочным фейсом. Кроме того, почему бы предметно не обсудить, чем страшно ручное прибавление +1 к последнему id из _1SUIDCTL (с учетом 36ричной конечно) при type_id = виду справочника и запись его в 2 таблицы в транзакции ?. | |
| 7
- 04.02.2013 - 20:23
| (6) Попробуй использовать постоянное OLE-подключение. | |
| 8
- 04.02.2013 - 20:33
|
6-Aristo_big > Зачем тебе справочник, если он монопольно захвачен? Ты пишешь разговор, и захват справочника непрерывен? Или пока бла-бла-бла, можно не торопясь завиксировать звонок? И т.д. Инкремент элемента вшит в движок 1С, отлажен в многопользовательском режиме, работает на всей линейке NT. И НАДЕЖЕН. | |
| 9
- 04.02.2013 - 20:39
|
3-Aristo_big > Перечитай себя. Нафига эту таблицу делать частью базы? Из любви к искусству? Пусть лежит себе в сторонке. А из базы, если приспичило, к ней неспешно подключайся. | |
| 10
- 05.02.2013 - 00:10
|
(6) Основная, очень творческая задача - через API перехватить номер входящего звонка с софтфона в 1С с дальнейшим быстрым поиском его по определившемуся номеру, чтобы еще до поднятия трубки открылась форма клиента с этим номером. Сам перехват уже сделан отдельным экзешником, теперь вопрос куда лучше этот номер сунуть: в саму 1С в справочник через SQL или в сторонний файл. Оле не рассматривается по следующей причине: все юзеры на терминале, звонилка на локальной машине. Коннектить ради этой микрозадачи по сети еще по соединению на каждое место менеджера "колл-центра" нелогично. (8) Справочник естественно, монопольно не захвачен. "Запись разговора" не ведется, только после момента определения номера сервером IP телефонии и передачи его во внешний источник, вот тут и вопрос если будет INSERT в справочник, то будет блокировка не больше чем запись элемента в 1С. (сама передача реализована). Инкремент элемента представляет собой изменение двух таблиц в транзакции. С периодическими реквизитами (которые придумал Сатана) - было бы 3. При необходимости вполне можно все это делать средствами SQL. Понятно, что лучше делать методами 1С, но в случае внешней записи при понимании - почему бы нет. (9) В большинстве случаев я согласен, но в данном случае есть особенности проекта. По сути создана CRM с колл - центром, и хоть элементы справочника не будут нигде ссылками - есть логика хранить их в базе, как минимум потому что на основе истории входящих звонков происходят дальнейшие пользовательские действия в системе, а внешний файл, сам понимаешь, может потеряться. И подключаться надо спешно. | |
| 11
- 05.02.2013 - 00:13
| (8) добавлю, звонок нужно зафиксировать до "бла-бла-бла", в момент звучания рингтона на софтфоне, и в идеале до поднятия трубки - открыть окно клиента в 1С. Поэтому скорость тут имеет значение. | |
| 12
- 05.02.2013 - 00:18
| Коллеги, кстати, может быть есть возможность извне открыть форму справочника для пользователя в уже существующем соединении ? Другими словами: звонит звонок,внешняя программа перехвата по ОЛЕ не создает новое соединение а именно в сеансе пользователя открывает окно клиента (и фиксирует звонок в истории) Это было бы идеально, вопрос отпал бы сам по себе. А сейчас видится, что неважно на каком варианте остановлюсь - придется использовать ОбработкуОжидания с анализом изменений в файле/справочнике. | |
| 13
- 05.02.2013 - 00:20
|
10-Aristo_big > Нет тут никакого творчества. Нужна внешняя компонента, которая будет генерировать для 1С ВнешнееСобытие. Задача уже сто лет как решена. Рарус:СофтФон http://www.telefon1c.ru/asterisk/ http://www.myasterisk.ru/1casterisk | |
| 14
- 05.02.2013 - 00:38
|
(13) Спасибо, Ментор, я не знал что есть google. 1. В теме есть тег "v7", решение под 8ку. 2. Решение под астерикс, под свич РТУ он не подходит. Протоколы не до конца совместимы. | |
| 15
- 05.02.2013 - 01:01
|
14-Aristo_big > Наздоровье. 1. Где в предложении "Нужна внешняя компонента, которая будет генерировать для 1С ВнешнееСобытие" ты увидел платформу? 2. Теперь ты знаешь про гугл. 3. То что у вас v7, что протоколы у вас несовместимые - так это вы сами себе злобные буратины, никто не заставлял обмазываться-то | |
| 16
- 05.02.2013 - 02:00
|
10-Aristo_big > Нагородиииил...... Итак, приходит сигнал с номером звонка. Запись этого сигнала (с записью времени, номером, без поиска в таблице) есть определение по индексу последнего ИД, инкремента ИД, поиска по индексу ближайшей удаленной записи (выборка до первого найденного элемента, или установка на дозапись) - все эти операции выполнятся мухой. Далее, чтоб сопоставить номер с контрагентом, надо обратиться к справочнику контрагентов. И искать в нем этот самый номер. Беда в том, что этих номеров - неопределенное количество (или заставишь контрогентов пользоваться одним номером?). Неопределенное количество полей в записи не бывает, а любое "достаточно" быстро окажется "недостаточным". Опять же индексация, без которой поиск неимоверно замедлится. Значит, номера надо в отдельный файл (структура номер+ссыла на контрагента), для поиска. Потом ищется запись в справочнике Контрагентов соответствующая запись, и отрисовывается форма. Еще перед вызовом формы надо организовать список значений с параметрами (хотя бы с номером телефона). И что занимает больше времени? Неужто запись таблицы простейшей структуры номер+время? Надо сделать "творчески"? Ню-ню, "творец". Не забудь только о совместном доступе. И о том, что одновременно (с разницей в милисикунды) на АТС может поступить несколько звонков... | |
| 17
- 05.02.2013 - 02:17
|
+16 И это только нулевой слой. Нет, я не об администрировании этого безобразия... Как мы будем распределять полученный сигнал (или ссылку на уже сформированную запись звонка) по пользовательским сеансам? А неизвестный номер как? Случайный? Ась? Подумал? Правда, штоль? :D Или, как у дитё, первым делом "конфетка"? | |
| 18
- 05.02.2013 - 02:25
|
16-VZ > А еще ты забыл про историю звонков, разбор речи, анализ переговоров и подбор приоритетного оператора для ответа, если мы говорим о CRM. Как ее можно было начать строить на базе клюшек без ms lync'a я вообще не понимаю. Ну или у них там три калеки две чумы с графиком не больше 8 часов в день, а туда же... call-центр у него... Кстате, господа монстры, кто знает, появились аналоги связки MS Exchange Server + Lync Server? Или с тех пор как они Skype купили надежды нет? | |
| 19
- 05.02.2013 - 02:52
|
18-Reaper > Номер+время - вот тебе зачин для истории... Это все скушная материя, весящая несколько килострок, для нашего аффтара не интересна.... "Ну или у них там..." - у них там молодой горячий Щазсбацаю... А что, он же "настоящий программист" :D | |
| 20
- 05.02.2013 - 06:47
|
(18,19) одноЭсники - они все такие добб... пардон, дятлы задачу реалтайма пытаются решать средствами идиотов а все остальные они прсто тупые, пишут для этого специальные системы | |
| 21
- 05.02.2013 - 06:49
|  | |
| 22
- 05.02.2013 - 07:28
|
с прискорбием признаю правоту Хелен. клюшки, да и вообще виндовс платформы для риалтайма ... | |
| 23
- 05.02.2013 - 07:45
|
Может буду и не первым, но... может лучше использовать для этих целей небухгалтерский продукт, например такой, как Microsoft C# Sharp ? Имхо такой подход будет нативнее, а стоимость разработки можно будет даже снизить :-) | |
| 24
- 05.02.2013 - 07:57
|
19-VZ > Не, настоящие программисты вон тут собрались... с риалтаймом и до диезом... facepalm.jpg | |
| 25
- 05.02.2013 - 08:39
| (24) завидуешь? смотри не умри от зависти | |
| 26
- 05.02.2013 - 08:47
|
0-Aristo_big >Cначала вычисляешь максимальный ИД: select max(id) from [ТвойСправочник] А затем на его основе формируешь новый: char buff[9]; CString newID; newID = _itoa(strtol(MAX_ID, NULL, 36) + 1, buff, 36)); newID.MakeUpper(); Как-то так :) | |
| 27
- 05.02.2013 - 08:49
| еще один.... | |
| 28
- 05.02.2013 - 08:49
|
(27)завидуешь? смотри не умри от зависти :))))))))))))) | |
| 29
- 05.02.2013 - 08:50
| зато я не умру от дурости | |
| 30
- 05.02.2013 - 12:36
| (16), (17) все как Вы сказали. Номера в отдельном подчиненном справочнике, номер пишется в CODE, оно индексировано. Поиск клиента и открытие формы - миллисекунды, об этом я и не спрашивал. и тут приходится признать, что отчасти неправильно описал задачу. Колл-центр это круто сказано, распределения по свободным пользователям нет. Клиент звонит уже известному менеджеру. Менеджер, которому адресован звонок - ясен на момент звонка, так как у каждого свой аккаунт на сервере и свой входящий номер. Менеджеров всего две-четыре штуки, и им нужно чтобы открывалась форма клиента, в которой и через которую в момент разговора делались определенные действия. То есть задача явно не такая чтобы придумывать трудоемкое решение. Единичные сбои никого сильно не обидят. По идее при звонке с разницей в миллисекунды - первый звонок при обработке перед получением ID заблокирует таблицы на запись, получит последний ID, увеличит его и запишет, таблицы разблокируются, далее запишется второй звонок. У каждого из менеджеров включена обработка ожидания (например, каждые 3-5 секунд), находится последний необработанный звонок из того же справоника куда пишем, находится клиент и открывается одна из его форм. Обработку ожидания сейчас заменяю созданием компоненты под 1С, генерирующей внешнее событие. Пока не знаю, хватит ли мозгов. | |
| 31
- 05.02.2013 - 12:43
| (18) неправильно описал задачу. О полноценном Call- центре речь не идет , так как звонок адресный определенному сотруднику а не свободному оператору. Сотрудников мало, компания небольшая. В принципе сейчас пытаюсь сделать внешнюю компоненту, которая генерирует внешнее событие, подключаясь к Zoiper Biz через COM - интерфейс. "Костыль" уже есть - програмку на VB написал в которой обработка внешнего события перехватывает номер, стараюсь сделать из нее dll чтобы обработать в 1С без внешних подключений. | |
| 32
- 05.02.2013 - 12:45
| (23) это модуль, тесно завязанный с уже существующими процессами в управленческой базе на семерке, входящих звонков немного, поэтому такой выбор: делать в уже существующей системе, не городя огородов | |
| 33
- 05.02.2013 - 12:48
| 18-Reaper > у тебя ответы пусть с вызовом но по делу, а я из себя топ- уровень не строю, но ожидал аргументов "против", а вместо этого пришли гуру программинга с пальцами "не делай этого малыш" :) | |
| 34
- 05.02.2013 - 12:57
| (29) Осторожно, можно умереть от отсутствия мужского ... внимания :-)))) | |
| 35
- 05.02.2013 - 13:25
|
32-Aristo_big, если звонков не много, может отдельный процесс? В нём поднять OLE-соединение к БД (или поднимать периодически), и создавать уже внутри всё средствами БД. Я когда-то поднимал 7ку через DCOM даже на удаленной машине. Просто лезть в потроха 1С-ки не из 1С-ки как бы не совсем корректно. Это запросто может быть дополнительная куча головняка в плане администрирования. Я когда-то работал над вопросом ускорить бухгалтерские отчеты и были весомые аргументы не в пользу VFP. Остановился на DCOM + 1C++ | |
| 36
- 05.02.2013 - 13:46
|
35-Том > Здесь не только "не в пользу VFP", здесь вообще нет обоснования лепить "собственный инкремент таблицы". Вообще аргументов никаких нет, кроме деЦЦких обид. Получил две строки (время и номер) - отдай 1С. | |
| 37
- 05.02.2013 - 14:00
|
+36 Вообще, из писанины ТС вырисовывается совершенно ненужный "бантик". Непонятно, зачем вообще нужна форма Контрагента, если достаточно спозиционироваться на элементе списка, и далее вызывать нужный отчет (взаимозачеты, или что-то подобное). И какая нужда лепить статистику звонков для нескольких убогих - хз... "Бантик". Во всей красе. | |
| 38
- 05.02.2013 - 14:38
|
согласна с умными мужчинами лог-файл и должен быть лог-файлом, а не справочником непойми-чего а 1с должна его обрабатывать | |
| 39
- 05.02.2013 - 14:48
| (37) рыба без велосипеда - это не готично | |
Интернет-форум Краснодарского края и Краснодара |
