![]() | [1] [2] |
v7: База, ДБФ, нужно записать новый элемент из скрипта на VBS через SQL Дано: База дбф, драйвер VFP OLE DB. Нужно из приложения на Visual Basic записать новый элемент справочника. Метод подключения через OLE не устраивает (медленно и избыточно). В принципе все понятно кроме одного: как самостоятельно сгенерировать новый ID справочника. Кто нибудь может подсказать ? |
Не днлай этого. Не надо. |
не слушай. разрешаю. только купи сначала мыло и веревку качественную - меньше потом мучаться будешь |
(1), (2) . Аргументы ? Страх нарушить структуру БД ? Справочник - один. По сути это лог входящих звонков с сервера IP телефонии. Он нигде не будет ссылкой, поэтому повреждение его не ударит по базе. Нарушение ID внутри него как я понимаю тоже ударит только по нему. Но появиться он должен в момент входящего рингтона, тут скорость важна, поэтому OlE- подключение и выгрузку загрузку не очень хотелось бы использовать. Как я понимаю, речь идет о изменении 2 таблиц - таблицы самого справочника и таблицы 1SUIDCTL. |
[img]http://brodude.ru/wp-content/uploads/2012/10/BroDude.ru-17.10.2012.208-630x546.jpg[/img] |
3-Aristo_big > Раз не понимаешь - делать нельзя. Будешь понимать - поймешь, почему нельзя. Рассуждения (3) неверны. Выводы неверны. Метод решения - тоже. |
(5) Я не против того, чтобы перечислили правильные методы. Кроме того, сам сделаю несколькими, потестирую, какие проблемы. Я же не собираюсь решение запускать сразу. Однако сейчас только пишете "делаешь плохо", с загадочным фейсом. Кроме того, почему бы предметно не обсудить, чем страшно ручное прибавление +1 к последнему id из _1SUIDCTL (с учетом 36ричной конечно) при type_id = виду справочника и запись его в 2 таблицы в транзакции ?. |
(6) Попробуй использовать постоянное OLE-подключение. |
6-Aristo_big > Зачем тебе справочник, если он монопольно захвачен? Ты пишешь разговор, и захват справочника непрерывен? Или пока бла-бла-бла, можно не торопясь завиксировать звонок? И т.д. Инкремент элемента вшит в движок 1С, отлажен в многопользовательском режиме, работает на всей линейке NT. И НАДЕЖЕН. |
3-Aristo_big > Перечитай себя. Нафига эту таблицу делать частью базы? Из любви к искусству? Пусть лежит себе в сторонке. А из базы, если приспичило, к ней неспешно подключайся. |
(6) Основная, очень творческая задача - через API перехватить номер входящего звонка с софтфона в 1С с дальнейшим быстрым поиском его по определившемуся номеру, чтобы еще до поднятия трубки открылась форма клиента с этим номером. Сам перехват уже сделан отдельным экзешником, теперь вопрос куда лучше этот номер сунуть: в саму 1С в справочник через SQL или в сторонний файл. Оле не рассматривается по следующей причине: все юзеры на терминале, звонилка на локальной машине. Коннектить ради этой микрозадачи по сети еще по соединению на каждое место менеджера "колл-центра" нелогично. (8) Справочник естественно, монопольно не захвачен. "Запись разговора" не ведется, только после момента определения номера сервером IP телефонии и передачи его во внешний источник, вот тут и вопрос если будет INSERT в справочник, то будет блокировка не больше чем запись элемента в 1С. (сама передача реализована). Инкремент элемента представляет собой изменение двух таблиц в транзакции. С периодическими реквизитами (которые придумал Сатана) - было бы 3. При необходимости вполне можно все это делать средствами SQL. Понятно, что лучше делать методами 1С, но в случае внешней записи при понимании - почему бы нет. (9) В большинстве случаев я согласен, но в данном случае есть особенности проекта. По сути создана CRM с колл - центром, и хоть элементы справочника не будут нигде ссылками - есть логика хранить их в базе, как минимум потому что на основе истории входящих звонков происходят дальнейшие пользовательские действия в системе, а внешний файл, сам понимаешь, может потеряться. И подключаться надо спешно. |
(8) добавлю, звонок нужно зафиксировать до "бла-бла-бла", в момент звучания рингтона на софтфоне, и в идеале до поднятия трубки - открыть окно клиента в 1С. Поэтому скорость тут имеет значение. |
Коллеги, кстати, может быть есть возможность извне открыть форму справочника для пользователя в уже существующем соединении ? Другими словами: звонит звонок,внешняя программа перехвата по ОЛЕ не создает новое соединение а именно в сеансе пользователя открывает окно клиента (и фиксирует звонок в истории) Это было бы идеально, вопрос отпал бы сам по себе. А сейчас видится, что неважно на каком варианте остановлюсь - придется использовать ОбработкуОжидания с анализом изменений в файле/справочнике. |
10-Aristo_big > Нет тут никакого творчества. Нужна внешняя компонента, которая будет генерировать для 1С ВнешнееСобытие. Задача уже сто лет как решена. Рарус:СофтФон [url]http://www.telefon1c.ru/asterisk/[/url] [url]http://www.myasterisk.ru/1casterisk[/url] |
(13) Спасибо, Ментор, я не знал что есть google. 1. В теме есть тег "v7", решение под 8ку. 2. Решение под астерикс, под свич РТУ он не подходит. Протоколы не до конца совместимы. |
14-Aristo_big > Наздоровье. 1. Где в предложении "Нужна внешняя компонента, которая будет генерировать для 1С ВнешнееСобытие" ты увидел платформу? 2. Теперь ты знаешь про гугл. 3. То что у вас v7, что протоколы у вас несовместимые - так это вы сами себе злобные буратины, никто не заставлял обмазываться-то |
10-Aristo_big > Нагородиииил...... Итак, приходит сигнал с номером звонка. Запись этого сигнала (с записью времени, номером, без поиска в таблице) есть определение по индексу последнего ИД, инкремента ИД, поиска по индексу ближайшей удаленной записи (выборка до первого найденного элемента, или установка на дозапись) - все эти операции выполнятся мухой. Далее, чтоб сопоставить номер с контрагентом, надо обратиться к справочнику контрагентов. И искать в нем этот самый номер. Беда в том, что этих номеров - неопределенное количество (или заставишь контрогентов пользоваться одним номером?). Неопределенное количество полей в записи не бывает, а любое "достаточно" быстро окажется "недостаточным". Опять же индексация, без которой поиск неимоверно замедлится. Значит, номера надо в отдельный файл (структура номер+ссыла на контрагента), для поиска. Потом ищется запись в справочнике Контрагентов соответствующая запись, и отрисовывается форма. Еще перед вызовом формы надо организовать список значений с параметрами (хотя бы с номером телефона). И что занимает больше времени? Неужто запись таблицы простейшей структуры номер+время? Надо сделать "творчески"? Ню-ню, "творец". Не забудь только о совместном доступе. И о том, что одновременно (с разницей в милисикунды) на АТС может поступить [b]несколько[/b] звонков... |
+16 И это только нулевой слой. Нет, я не об администрировании этого безобразия... Как мы будем распределять полученный сигнал (или ссылку на уже сформированную запись звонка) по пользовательским сеансам? А неизвестный номер как? Случайный? Ась? Подумал? Правда, штоль? :D Или, как у дитё, первым делом "конфетка"? |
16-VZ > А еще ты забыл про историю звонков, разбор речи, анализ переговоров и подбор приоритетного оператора для ответа, если мы говорим о CRM. Как ее можно было начать строить на базе клюшек без ms lync'a я вообще не понимаю. Ну или у них там три калеки две чумы с графиком не больше 8 часов в день, а туда же... call-центр у него... Кстате, господа монстры, кто знает, появились аналоги связки MS Exchange Server + Lync Server? Или с тех пор как они Skype купили надежды нет? |
18-Reaper > Номер+время - вот тебе зачин для истории... Это все скушная материя, весящая несколько килострок, для нашего аффтара не интересна.... "Ну или у них там..." - у них там молодой горячий Щазсбацаю... А что, он же "настоящий программист" :D |
(18,19) одноЭсники - они все такие добб... пардон, дятлы задачу реалтайма пытаются решать средствами идиотов а все остальные они прсто тупые, пишут для этого специальные системы |
[img]http://www.kokoko.ru/uploads/posts/2010-10/thumbs/1286337829_1285652823_995554_surovyij-gorod-chelyabinsk.jpg[/img] |
с прискорбием признаю правоту Хелен. клюшки, да и вообще виндовс платформы для риалтайма ... |
Может буду и не первым, но... может лучше использовать для этих целей небухгалтерский продукт, например такой, как Microsoft C# Sharp ? Имхо такой подход будет нативнее, а стоимость разработки можно будет даже снизить :-) |
19-VZ > Не, настоящие программисты вон тут собрались... с риалтаймом и до диезом... facepalm.jpg |
(24) завидуешь? смотри не умри от зависти |
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)завидуешь? смотри не умри от зависти :))))))))))))) |
зато я не умру от дурости |
(16), (17) все как Вы сказали. Номера в отдельном подчиненном справочнике, номер пишется в CODE, оно индексировано. Поиск клиента и открытие формы - миллисекунды, об этом я и не спрашивал. и тут приходится признать, что отчасти неправильно описал задачу. Колл-центр это круто сказано, распределения по свободным пользователям нет. Клиент звонит уже известному менеджеру. Менеджер, которому адресован звонок - ясен на момент звонка, так как у каждого свой аккаунт на сервере и свой входящий номер. Менеджеров всего две-четыре штуки, и им нужно чтобы открывалась форма клиента, в которой и через которую в момент разговора делались определенные действия. То есть задача явно не такая чтобы придумывать трудоемкое решение. Единичные сбои никого сильно не обидят. По идее при звонке с разницей в миллисекунды - первый звонок при обработке перед получением ID заблокирует таблицы на запись, получит последний ID, увеличит его и запишет, таблицы разблокируются, далее запишется второй звонок. У каждого из менеджеров включена обработка ожидания (например, каждые 3-5 секунд), находится последний необработанный звонок из того же справоника куда пишем, находится клиент и открывается одна из его форм. Обработку ожидания сейчас заменяю созданием компоненты под 1С, генерирующей внешнее событие. Пока не знаю, хватит ли мозгов. |
(18) неправильно описал задачу. О полноценном Call- центре речь не идет , так как звонок адресный определенному сотруднику а не свободному оператору. Сотрудников мало, компания небольшая. В принципе сейчас пытаюсь сделать внешнюю компоненту, которая генерирует внешнее событие, подключаясь к Zoiper Biz через COM - интерфейс. "Костыль" уже есть - програмку на VB написал в которой обработка внешнего события перехватывает номер, стараюсь сделать из нее dll чтобы обработать в 1С без внешних подключений. |
(23) это модуль, тесно завязанный с уже существующими процессами в управленческой базе на семерке, входящих звонков немного, поэтому такой выбор: делать в уже существующей системе, не городя огородов |
18-Reaper > у тебя ответы пусть с вызовом но по делу, а я из себя топ- уровень не строю, но ожидал аргументов "против", а вместо этого пришли гуру программинга с пальцами "не делай этого малыш" :) |
(29) Осторожно, можно умереть от отсутствия мужского ... внимания :-)))) |
32-Aristo_big, если звонков не много, может отдельный процесс? В нём поднять OLE-соединение к БД (или поднимать периодически), и создавать уже внутри всё средствами БД. Я когда-то поднимал 7ку через DCOM даже на удаленной машине. Просто лезть в потроха 1С-ки не из 1С-ки как бы не совсем корректно. Это запросто может быть дополнительная куча головняка в плане администрирования. Я когда-то работал над вопросом ускорить бухгалтерские отчеты и были весомые аргументы не в пользу VFP. Остановился на DCOM + 1C++ |
35-Том > Здесь не только "не в пользу VFP", здесь вообще нет обоснования лепить "собственный инкремент таблицы". Вообще аргументов никаких нет, кроме деЦЦких обид. Получил две строки (время и номер) - отдай 1С. |
+36 Вообще, из писанины ТС вырисовывается совершенно ненужный "бантик". Непонятно, зачем вообще нужна форма Контрагента, если достаточно спозиционироваться на элементе списка, и далее вызывать нужный отчет (взаимозачеты, или что-то подобное). И какая нужда лепить статистику звонков для нескольких убогих - хз... "Бантик". Во всей красе. |
согласна с умными мужчинами лог-файл и должен быть лог-файлом, а не справочником непойми-чего а 1с должна его обрабатывать |
(37) рыба без велосипеда - это не готично |
Текущее время: 23:24. Часовой пояс GMT +3. | [1] [2] |