Использует? Этож круче чем ДБФ по сути - что хочешь то в ячейку и пихнешь, хочешь вниз хочеш в бок, но я не разу не видел, чтобы его использовали. Напрашивается вопрос - почему?

Имелось в виду XML?

(1) Судя по всему, что сказал, то и имел в виду...
(0) Книгу по Базам Данных почитай.

неа Файл->Новый->Таблица <- Вот она родимая.
Я тут подумал - структурка не жесткая из 1С-вполне читабельна.
На счет скорости правда слабовата :(. Но так себе ни чего возможности :)
А ничего не видел

(2) На какой предмет?

(0) Хорошая идея...

Я к тому что у нее структура гибкая, условно не нормированные размеры ячейки и расщифровки.

(5)А что здесь хорошего? А совместимость?!

(6)Расшифровка не сохраняется...

(7) Совместимость с чем? 1Са с 1С-ом :)

(7) Да просто я ничего подобного, за много лет не видел. Это ж додуматься надо...

(9)Все равно объекты не сохраняются... С XML знаком?

(8)Уверен?

(12)Если в расшифровке - объект, то уверен.

//*******************************************
Процедура Сформировать()
   Т = СоздатьОбъект("Таблица");
   Область = Т.Область(1,1,1,1);
   Область.Текст = "Область";
   Область.Расшифровка("Расшифровка");
   Т.Записать("C:\tab.mxl");    
КонецПроцедуры
В расшифровке будет {"S","0","0","0","0","0","Расшифровка"}
Правда на тот форматец, но всеже.
(9) Знаком, пожевал его регистровые примочки немножко :)
Меня всетаки интересует вопрос "почему НЕТ"?
А вразумительного ответа я не услышал.
Есть только свои наблюдения - скорость, а в другом все клево.
По отношению к текстовому файлу не надо гемороиться с разделителями.

Зачем объект? Просто его строковое представление.

Думаю, что она хранит там что то типа ЗначениеВСтроку, т.е. по барабану объект или нет. Но точно не скажу, надо будет попробовать.
Но в целом согласен и медленно и никакой структуры - mxl в качестве переноса данных в топку.

(15)Изобрази строковое представление, например, расходной накладной.

по отношению к ДБФ - структура не жесткая.
По отношению к XML - не надо помнить и воссоздавать набор тегов.
файлик в (14) весит 267 байт :)
Для небольших объемов просто шик :)

17. Запросто. {"Документ","РасходнаяНакладная","CBЧ000000001","21.05.2004"}

(17){"O","0","0","123","0","0","     12225   "}

+19. Это заголовок пакета. Внутри пакета - содержимое дока.

(16) За что тебе звездочки дали?
Ни какой структуры :)
1. в первой строке квасишь себе название полей, в расшифровку кладешь список описатель поля.
2. в 1+N загоняешь данные.
3. в 1+N+1 повторяешь то, что делал в 1.
Вот тебе и структура.
А по скорости 1С-овским язычком уступает раз в 20-30, ну и что?
Достаточно написать такой алгоритм, котрый на столько-же тормознет твою выгрузку в ДБФ :)

Да еще в добавок количество так называемых полей, вернее его лимит мне не известен.

22 За отсутствие наездов.
Базы данных на текстовых файлах не писал? Можно и на велосипеде покататься

(19,20)Я неправильно выразился. Представить можно. Но что это дает в итоге?!

Это был не наезд, это была досада на отсутствие фантазии.

25. Если добавить уникальный IDD, то получится МОД через mxl :)

trdm, мы очень дорожим здешней Волшебной атмосферой.

В (0) Гнилая идея...
Круче - база На одном ДБФ-е с четыремя полями...
VID,ID,ParentID,Text...
Я из Таких несколько раз данные в 1С тянул...

Я за. Но только кто же будет вас дразнить? заставлять напрязгать фантазию?
Мягко провоцировать?

(29)Согласен
(30)А оно надо? Мне есть чем фантазию занять :)

Это не идея, это вопрос. Ну тупой я на эту тему.
Я вижу преимущества, недостатки и спрашиваю, чего больше, а мне прошлогодний помидор.

(31) Мне тоже. Вот сижу разбираюсь почему метод в заявленный GetNParams с параметрами *plParams = 0; требует 2-х параметров.
Ну сырой я еще в этом.

(32) Видишь ли... промышленные технологии иногда отвергали самые замечательные идеи по самым разным причинам... примеры приводить сейчас влом, но их немало.
Посему... есть СТАНДАТНЫЕ процедуры обмена... DBF, ХМL... Зачем тратить время на "изобретение велосипеда"
.
PS: Если интерасна подобная тема, поищи в архивах форума... было предложение обмен устраивать через ini...

(34) По крайней мере наиболее обстоятельный ответ. Спасибо.
Отдохнул немного. Через ini - геморой, задолбешся идентификаторы изобретать.
Это я и так врубаюсь. :)

(35) Врубаешься? ну ну... ветку то найди... почитай...
Автор поупрямее тебя был ;-))

(34) Авторитетом взял :) Про велосипед уже сказали - что значит грамотно изложить.

(36) Работал с ini, немножко. Параметры в нем неплохо хранить типа int, LPCTR, система мара работает с файлом, ты просто устанавливаешь сохраняещь, или востанавливаешь параметры по идентификатору. а что такого?

(37) Я не в курсе о местных авторитетах. Нет так нет.
Каждый сходит с ума по своему. у меня свой путь.

(trdm) Что главное в обмене?
Скорость? Тогда ДБФ...
Быстрая выборочная загрузка? Тогда ДБФ + Индексы...
Я ни одного плюса не вижу ни в ini, ни в MXL...

(38) Да, собственно, ничего.
Просто почитай с точки зрения аргументации автора, а не техники вопроса.
PS: На работе бы я за подобное "предложение" посоветовал бы не отвлекаться и заняться делом... :-)

Кстати, насчет размера - ЗапуститьПриложение() - архивируешь Раром - и ДБФ - будет на порядок меньше твоего MXL-я, то же сжатого.

(40)В МХЛ достаточно удобно хранить разношерстные данные, н езаводя кучу таблиц и не выпендриваясь с преобразованиями

Я спросил, для того чтобы просто знать лезть мне в эту лабуду или нет.
Еще вопрос, мелькало слово "тригеры" что это такое? Где почитать?

NS ответил вторым постом

(43) Желание хранить всю выгрузку в одном файле - это просто бзик....
Хотя - после архивирования - у меня и получается один файл...
И какие в mxl разношерстные данные? Он только текст хранит!!! строки!
Легко двумерный массив эмулируется одномерным (ну это понятно)
И mxl можно заменить ДБФ-ом с одним! полем (если расшифровка еще - то с двумя)
С Чудовищной разницей в пользу ДБФ-а по объему и скоростью работы + возможность индексирования.

(42) спасибо, я два года назад такое писал + auto-atach к электронке и отправлял по почте. старый rar.exe, неплохо с dbf работает.

(45) на счет тригеров?

(48)Там же. Есл на пальцах, то процедуры срабатывающие на сервере БД в момент каких-либо событий

(46)По скорости спорить не буду. Но запихнуть структуру туда проще чем в набор табличек - разворачивать проще. Сдается мне что xBase не прошел стороной.
Пока очень мало работал с хмл, но собираюсь наверстать - (имхо)очень удобно.
Возможно я и изменю свое мнение, потом. Все познается в сравнении.

Скуль? :( А у меня клиент его решил не задействавать :( Терминалит.
Как быть? ODBC или ВК?

(50) XML очень тормозной.

Качнул сегодня ODBCSQL (клево что с исходниками).
Без сервака конечно затык, но думаю извернусь.

(+52) Но очень удобный и распространенный.

Забыл сказать спасибо. :)

Хм. 52+54 На разные чаши весов. Согласись, что для небольших данных, может быть более выгодным решением.

(56) Для кого - как.
Я быстро пишу переносы.

(55)Пожалуйста. Только хотел спросить ты не спутал божий дар и яишницу?
Храняться данные либо в файловом виде (ДБФ) либо на сервере БД SQL (разные бывают). А вот ОДБС, ВК и пр. это то как ты к ним доступ получаешь.

Не спутал. Просто позно уже. Время не для обстоятельных вопросов.
Просто имел ввиду напрямую (ODBC) или какого нибудь надежного клиента (ВК)?

Тут не подскажу - сам не юзаю

А почему не mdb? Пишешь небольшую dll-ку типа Создать таблицу, добавить поле, создать связь и выгружаешь что угодно.

А зачем плодить сущности?

(40) Скорость на DBF?
Ну, если для большого числа полей это и справедливо, то для числа полей 1-5 DBF по скорости на порядок уступает тексту.

(63) ДБФ на порядок выигрывает у текста... т.к. нет функций разборки текста.
+ индексы
+ типизация

- типизация - это тоже надо учитывать. Не совсем пригодно для разнородных данных. Текст и ХМЛ здесь выигрывают в гибкости...

P.S. все зависит от задачи

(64) Как это нет функций? Как угодно строку можно разобрать - были бы руки.
Типизировать можно и в тексте - какая разница - число в строку, строку в число.
Индексы опять же имеют смысл при работе с большим количеством полей, и особенно - при поиске по колючам. Если же нужно просто перебрать все записи - DBF здесь намного неповоротливей. По крайней мере штатными средствами.

Строку можно разобрать... Но это затраты времени на разбор...

Индексы - штука очень удобная... не надо делать на уровне кода действий... Например, нужно обработать записи ДБФ с сортировкой по дате/времени - в ДБФ накладываешь индекс на сущ файл и все.... А в тексте - сначала все нужно загрузить, потом сортировать.

Перебор всех записей в общем случае что в ДБФ, что в тексте - одинаково... фиолетово. Но если перебор нужно с условием - опять таки индекс рулит, и работает быстрее...

Просто кошек нужно уметь правильно готовить... на существующем слегка дебильноватом керогазе....  В общем то ДБФ изначально и придуман для организации упорядоченной выборки из произвольного массива записей... И делать это быстро....

Часто мелькает на форуме - типа не изобретай велосипед.
А я думаю так, если бы не изобретатели велосипедов, то нам до сих пор пешком ходить пришлось. Вот пример, придумали jpeg - круто, непревзойденно - все так и подумали, больше ничег нового, ан нет вот вам dejvu. Или zip и rar, вроде бы все конец пути, но получите же 7zip. Так пусть те у кого есть фантазия творят на благо остальным.

(66) Обработать записи с сортировкой - согласен, индексы удобней. Но тема была про экспорт/импорт - вот я об этом.
Простой перебор всех записей - ни фига не одинаково. Я тестировал это дело - разница бывает в разы. Вообще - DBF - это тот же самый текст, который 1С разбирает на значения своими встроенными путями, и пути эти - не идеальны.
...А если ещё добавить тот фактор, что структура данных в файле может меняться, что значения могут быть пустыми, что DBF больше весят по объёму - выигрыш очевиден... опять же - на небольшом количестве полей (про количество полей более 10 судить не берусь).

Моё мнение mxl- файл очень удобен, когда не критично время обработки, например выгрузка данных в бухгалтерию. Плюс - любой объект выгружается в виде дерева, что не требует анализа таблиц, и не ограничен форматом таблиц DBF, отсюда гибкость и простота настройки. Минус - большой файл. На счёт скорости ничего сказать не могу.

(68)
Текстовые файлы большого объема тяжело обрабатываются 1С.
Имею ввиду конечно стандартный 1с-овский объект "Текст", да и V7TextFile туда-же.
При анализе 260мб файла V7TextFile просто затыкался.
Правда если писать свои внешние компоненты, то все в порядке.

(0) Привет всем.
Его используют в программе консолидации отчётности Главная Книга http://acrk.kaluga.ru/product.htm

Файлы xml обрабатываются своей компонентой (если не ошибаюсь  xmlParser). Очень удобно использовать xml файла если надо единожды перелить данные, не потребуется писать свои обработки.

Я пробывал переливать документы из УПП 8 в Бух 77 с помощью xml всё отлично работает, по времени сносно, не прихлось гемороится с DBF. При необходимости изменений,  просто меняем правило вазгузки. Если использовать DBF, придётся исправлять код.

А весь этот сырбор с форматами, я думаю из за отсутствия хоть каких либо стандартов (посему каждый, как и я, когда начинает задумываться над "обменом" начинает изобретать велосипед). Как-бы не плохо было-бы ссылку здесь на статейку специалиста, по анализу и сравнению разных стандартов обмена, но я таких пока не встречал(статей). У нас народ такой: "я лучше изобрету пятиколесный тандем, чем проанализирую инфу про уже существующие наработки".
Посему просьба к Спецам по обмену: "изложите, пожалуста или дайте урлу на статью где все эти стандарты обмена данными рассматриваются, так как не только trdm и мне они нужны, но и многим начинающим "кулибинам".

Круто. Так что идея можно сказать нормальная,
со своими плюсами и минусами. Сенкс.