Чат

[Eugen Graf]

Скачай бесплатный ADO тулкит, линк есть в теме о базах данных. Там есть 5 примеров использования, в остальном думаю мы совместными усилиями сможем тебе помочь.

[delion]

EG у меня такие же задачи как и у FireFly вот пытался с помощью ADO тулкита записывать гиперссылку в базу данных на файл, но не чего не вышло ! Прописывается только заголовок, строка пути остаётся незаполненной. Ты с таким не сталкивался?

[Eugen Graf]

А каким образом ты это делаешь? Может быть, если это строка её нужно взять в кавычки?

[FireFly]

EG у меня такие же задачи как и у FireFly вот пытался с помощью ADO тулкита записывать гиперссылку в базу данных на файл, но не чего не вышло ! Прописывается только заголовок, строка пути остаётся незаполненной. Ты с таким не сталкивался?

У меня путь, в string виде нормально записывается. Что ещё надо?

[delion]

Eg! делаю вот таким образом:

[delion]

FireFly, eg, Ребят ну что не чего не подскажите больше, про запись ссылки в базу ?

[delion]

FireFly, Посмотри фотки что я выложил....у меня через стринг тоже прописывается путь но гиперссылка не работает (см. предыдущий пост)

[Viktor]

Посмотри настройки Microsoft Office Access!
Может быть он блокирует гиперссылки в целях безопасности

[delion]

Не эту табличку он всегда выводит....даже когда просто ссылку создаешь в самом access даже не через labVIEW ...

[FireFly]

Сейчас пишу клиент. Вот задумался над количеством циклов:
Сначала собирался сделать для всей работы с TCP один цикл. Т.е. сначала он просматривает (с таймаутом 0) очередь на наличие чего-нибудь, если обнаруживает в очереди команду (от интерфейса, или от самого себя, возможно появится ещё источник) - выполняет соответствующий Case (в котором скорее всего TCP Write, хотя возможны варианты (выход например)). Если очередь пустая выполнять цикл с TCP Read с таймаутом 300 мс. Если удалось что-нибудь прочитать - посылать в очередь главного (интерфейсного) цикла.
Но вот думаю правильно ли это? Вдруг поток команд в очереди станет постоянным (пока смутно себе это представляю) и не оставит времени на TCP Read? Стоит ли этого опасаться? Может стоит разделить на два цикла - один осуществляет постоянный TCP Read для получения команд с сервера, другой периодический TCP Write в случае появления объектов в его очереди? Не будут ли они конфликтовать друг с другом? Или предусмотреть добавление команды на TCP Read в очередь, а не как щас - по факту пустой очереди?

[Eugen Graf]

Думаю можно обойтись одним, но сделать приоритет записи данных выше, чем чтения. То есть если есть что записать, то выполнять сразу же после таймаута чтения, если записывать нечего то продолжать чтение.
Получается, что данные будут записываться максимум после одного таймаута. Если таймаут выставить например на 100 мс, то максимальная задержка при записи будет 100 мс. Если такая максимальная задержка устраивает, то можно делать так, иначе можно и два параллельных цикла сделать.

[FireFly]

Думаю можно обойтись одним, но сделать приоритет записи данных выше, чем чтения. То есть если есть что записать, то выполнять сразу же после таймаута чтения, если записывать нечего то продолжать чтение.
Получается, что данные будут записываться максимум после одного таймаута. Если таймаут выставить например на 100 мс, то максимальная задержка при записи будет 100 мс. Если такая максимальная задержка устраивает, то можно делать так, иначе можно и два параллельных цикла сделать.

Вдруг поток команд в очереди станет постоянным (пока смутно себе это представляю) и не оставит времени на TCP Read? Стоит ли этого опасаться?

[FireFly]

Ещё вопрос возник.
Почему ты во Flatten To String Function ставишь prepend array or string size? в значение False. Не очень понимаю за что отвечает этот вход (с английским нелады). Вообще когда надо ставить туда Default True, а когда False? Вот когда я делаю Flatten To String перед добавлением в очередь что лучше ставить?

[Eugen Graf]

Вдруг поток команд в очереди станет постоянным (пока смутно себе это представляю) и не оставит времени на TCP Read? Стоит ли этого опасаться?

Не могу точно ответить, наверное нужно пробовать.

Ещё вопрос возник.
Почему ты во Flatten To String Function ставишь prepend array or string size? в значение False. Не очень понимаю за что отвечает этот вход (с английским нелады). Вообще когда надо ставить туда Default True, а когда False? Вот когда я делаю Flatten To String перед добавлением в очередь что лучше ставить?

Это не так важно, главное чтобы и у Flatten и у Unflatten были установлены одинаковые параметры. Просто я привык, чтобы мне не добавляло автоматически какие то мне принципиально не нужные дополнительные данные.

[FireFly]

Если я правильно понимаю - у тебя клиент никак не следит за тем есть ли связь с сервером или нет. Сейчас только сервер опрашивает командой "alive" клиентов и если ответный "alive" не получен - считает их отвалившимися.
Как думаешь - стоит ли сделать так чтобы клиент тоже следил за соединением с сервером? Если да, то как? Аналогично слать серверу "ping" и ждать "pong"? Или просто смотреть приходят ли от сервера "alive" и если не приходят дольше Х сек, то считать связь оборванной?