К списку форумов К списку тем
Регистрация    Правила    Главная форума    Поиск   
Имя: Пароль:
Рекомендовать в новости

v7: База, ДБФ, нужно записать новый элемент из скрипта на VBS через SQL

Гость
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) рыба без велосипеда - это не готично


К списку вопросов
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск




Copyright ©, Все права защищены