Инсталяция:> dotnet add package sabatex.V1C77

или добавить через NUGET пакет sabatex.V1C77.

Добавить пространство имен: using sabatex.V1C77;

пример использованя: ---C#

     static void Main(string[] args)     {         // создаём строку соединения         var connection = new sabatex.V1C77.Models.Connection         {             DataBasePath = @"C:\demo\1SBUKRD", // путь к базе             PlatformType = sabatex.V1C77.Models.EPlatform1C.V77M, // платформа 1С77             UserName = "Админов", // имя пользователя             UserPass = "" // пароль или пустая строка         };          // соединяемся с 1С77         //          using (var _1c77 = sabatex.V1C77.COMObject1C77.CreateConnection(connection))         {             // перебор всего справочника Контрагенты             var contr = _1c77.GlobalContext.CreateObject("Справочник.Контрагенты");             if (contr.Method<double>("ВыбратьЭлементы") == 1)             {                 while (contr.Method<double>("ПолучитьЭлемент")==1)                 {                     if (contr.Method<double>("ЭтоГруппа") == 1) continue;                     var name = contr.GetProperty<string>("Наименование");                     Console.WriteLine(name);                 }             }         }     }   [/pre]
 
соответствие типов данных 1С7.7 и C# 
   строка - string
   число - doubl
   дата - DataTime
   остальное - V1C77COMObject
возможно использовать bool для замены double(0- false;1 - true) тогда выражение сократится к if (contr.Method("ВыбратьЭлементы"))

 &НаКлиенте

Функция ПроверитьСтроку(Строка, Фасет)

    Чтение = Новый ЧтениеXML;

    Чтение.УстановитьСтроку(

                "<Model xmlns=""http://v8.1c.ru/8.1/xdto"" xmlns:xs=""http://www.w3.org/2001/XMLSchema"" xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"" xsi:type=""Model"">

                |<package targetNamespace=""sample-my-package"">

                |<valueType name=""testtypes"" base=""xs:string"">

                |<pattern>" + Фасет + "</pattern>

                |</valueType>

                |<objectType name=""TestObj"">

                |<property xmlns:d4p1=""sample-my-package"" name=""TestItem"" type=""d4p1:testtypes""/>

                |</objectType>

                |</package>

                |</Model>");



    Модель = ФабрикаXDTO.ПрочитатьXML(Чтение);

    МояФабрикаXDTO = Новый ФабрикаXDTO(Модель);

    Пакет = МояФабрикаXDTO.Пакеты.Получить("sample-my-package");

    Тест = МояФабрикаXDTO.Создать(Пакет.Получить("TestObj"));



    Попытка

        Тест.TestItem = Строка;

        Возврат Истина

    Исключение

        Возврат Ложь

    КонецПопытки;

    

КонецФункции

    

&НаКлиенте

Процедура Модель(Команда)

    

    Сообщить(ПроверитьСтроку("01.01.2012","\d{2}\.\d{2}\.\d{4}"));

    Сообщить(ПроверитьСтроку("01.01.20121","\d{2}\.\d{2}\.\d{4}"));

    

КонецПроцедуры   

 USE acc_main

ALTER DATABASE acc_main SET RECOVERY SIMPLE

DBCC SHRINKFILE (acc_main, 50);

ALTER DATABASE acc_main SET RECOVERY FULL   

 BACKUP LOG BaseDB TO DISK = '<D:\Backup\Base_Log.trn'

DBCC SHRINKFILE (BaseDB_Log, 20) WITH NO_INFOMSGS   

  // Получение данных из OOo Base

   Попытка

      ServiceManager = Новый ComОбъект("com.sun.star.ServiceManager");

   Исключение

      Сообщить("Отсутствует приложение для загрузки файла");

   КонецПопытки;



     DatabaseContext = ServiceManager.CreateInstance("com.sun.star.sdb.DatabaseContext");

      

     //"Base1" - имя базы

     DataSource = DatabaseContext.getByName("Base1");

      

     //Логин и пароль, если их нет то пусто

     Connection = DataSource.GetConnection("","");

      

     //Создаем запрос

     Statement = Connection.createStatement();

     ResultSet = Statement.executeQuery("SEL ECT ""Model"" FR OM ""Price""");

      

     //Возврат результата

     Пока ResultSet.next() Цикл

        Сообщить(ResultSet.getString(1));

     КонецЦикла;

   

Если такое происходит, обратите внимание на следующее:
Посмотрите, какой режим восстановления (Recovery) стоит на закладке Options в свойствах базы данных. Он бывает Simple (простой, который требует наименьшего администрирования) или Full (полный, который обеспечивает наилучшую возможность восстановления данных после сбоя). В режиме Full возможен рост журнала транзакций (LDF), поскольку изменения базы данных накапливаются в этом журнале.

Уменьшение журнала транзакций зависит от операции резервного копирования (backup): если не делать резервное копирование, то лог транзакций в режиме Full будет расти.

Обратите внимание на пункт контекстного меню "Shrink Database" (shrink - англ. усадка, усушка, уменьшение). Эта операция уменьшает размер базы данных путем "удаления неиспользуемых страниц" ("remove unused pages").

В свойствах базы данных есть опция "Auto Shrink", которая активизирует автоматическое уменьшение базы, во время периодических проверок неиспользуемого места ("during periodic checks for unused space").

Для базы данных предприятия в свойствах базы я установил опцию Full Recovery. На этой же закладке я установил флажок Auto Shrink. Базу надо периодически архивировать, для чего я настроил автоматическое архивирование базы данных (каждое утро) и журнала транзакций (каждые 10 минут).

Режим восстановления базы данных:
Режимы восстановления базы данных (recovery models) баз данных SQL Server 2005, полное протоколирование (full), неполное протоколирование (bulk-logged), простая модель восстановления (simple)

Одно из важных решений, которые нужно принять при создании базы данных — в каком режиме восстановления будет работать база. Этот параметр выбирается на вкладке Options свойств базы данных в строке Recovery Model (Режим восстановления) (над списком остальных параметров). Изменить режим восстановления базы данных можно также при помощи команды A_lter DATABASE.

Всего предусмотрено три режима восстановления базы данных:
Full (режим полного протоколирования) — в этом режиме максимальное количество операций записывается в журнал транзакций. Журнал транзакций автоматически не обрезается. Этот режим обеспечивает максимальные возможности восстановления (за счет снижения производительности). Только в этом режиме вы можете использовать зеркальное отображение баз данных и автоматическую доставку журналов (log shipping). Именно этот режим выбирается по умолчанию для пользовательских баз данных, поскольку он настроен для базы данных model. Если изменить режим восстановления для базы данных model, то для создаваемых баз данных по умолчанию будет выбираться новый режим.

Bulk-logged (режим неполного протоколирования) — это компромисс между требованиями производительности и возможностями восстановления. При использовании этого режима запись в журнал практически отключается (в терминологии Microsoft — проводится минимальное протоколирование) для операций следующих типов:
- массовой вставки (команды BULK I_nsert, S_elect INTO, загрузка средствами bcp и т. п.);
- вставка/изменение больших двоичных данных (text, ntext, image);
- операции по созданию, перестроению и удалению индексов.

Автоматическая перезапись журналов транзакций при этом не производится, работа с транзакциями, не включающими в себя перечисленные операции, производится как обычно.

При работе в этом режиме вы лишаетесь возможности использовать журнал транзакций для восстановления (при утрате файлов данных, на момент времени или на метку транзакции), если в нем была хотя бы одна запись о перечисленных ранее операциях. Microsoft рекомендует не использовать этот режим восстановления на постоянной основе, а переключаться в него из режима Full на время выполнения больших операций массовой вставки, а потом возвращаться обратно.

Simple (простая модель восстановления) — максимальный выигрыш в производительности и удобстве работы за счет возможностей восстановления. Минимально протоколируются те же операции, что и в режиме восстановления Bulk-logged, а кроме этого, журнал транзакций автоматически очищается (блоками, размер которых изначально равен 256 Кбайт, но при необходимости он может быть автоматически увеличен). В результате вы получаете максимальную производительность и возможность не думать о потенциальной нехватке места в журнале транзакций. Но в этом режиме использовать журнал транзакций для восстановления уже не удасться. Вы не сможем даже выполнить резервное копирование журнала транзакций: команда BACKUP LOG в этом режиме сразу вернет ошибку.

Какой же режим восстановления выбрать?
Microsoft (в своих учебных курсах) рекомендует для рабочих баз данных выбирать только режим Full. Однако из опыта проведения автором этих самых учебных курсов и общения со слушателями можно сказать, что очень многие опытные администраторы сознательно настраивают для своих баз данных режим восстановления Simple. Значительное повышение производительности при операциях массовой вставки и при работе с большими двоичными данными вполне оправдывает некоторое снижение возможностей резервного копирования и восстановления. Что важнее для вашей задачи — дополнительные возможности восстановления или максимальная производительность, решать вам.

---

Рост журнала транзакций в 1С MS SQL Server

TEMPDB представляет собой системную базу данных Microsoft SQL Server, в которой хранятся временные таблицы, созданные как самим сервером, так и пользователями. Эта база данных создается заново при каждом перезапуске Microsoft SQL Server. По умолчанию размер этой базы данных неограничен и увеличение его осуществляется при необходимости автоматически, порциями по 10% от текущего размера TEMPDB. Однако эти параметры могут быть переопределены пользователем. По умолчанию, минимальный размер этой базы данных, который устанавливается при старте Microsoft SQL Server, определяется размером системной базы данных MODEL. Очистка журнала транзакций в этой базе данных производится автоматически, при этом удаляются только неактивные записи журнала транзакций.

При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы. Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, U_nion, DISTINCT и т.п.
Проблема

В процессе работы 1С:Предприятия 8 возможно значительное увеличение размера базы данных TEMPDB. Если размер диска, на котором расположена база данных TEMPDB, окажется недостаточным, работа 1С:Предприятия 8 может завершиться аварийно.
Решение

Если эта проблема проявляется регулярно, то рекомендуется переместить TEMPDB на другой диск большего размера.

Эту операцию можно выполнить следующим способом:

* определить логические имена файлов базы данных TEMPDB (колонка "NAME" результата выполнения процедуры). Для этого нужно в Query Analyzer выполнить следующую команду:

Код SQL

 

        USE tempdb

        GO

        EXEC sp_helpfile

        GO

   

* изменить месторасположение файлов базы данных TEMPDB с помощью команды A_lter DATABASE. Для этого нужно в Query Analyzer выполнить следующую последовательность команд:

Код SQL

 

        USE master

        GO

        A_lter DATABASE tempdb 

        MODIFY FILE (NAME = tempdev, FILENAME = 'D:\NewCat\tempdb.mdf')

        GO

        A_lter DATABASE  tempdb 

        MODIFY FILE (NAME = templog, FILENAME = 'D:\NewCat\templog.ldf')

        GO

   

3. Перезапустить Microsoft SQL Server.

Более подробное описание и рекомендации по использованию этих команд можно найти в документации по Microsoft SQL Server.