Наша сегодняшняя статья призвана помочь начинающим чайникам разобраться в лабиринтах электронных почтовых служб, коих в интернете существует немало. Мы рассмотрим достаточно тривиальный, но волнующих многих вопрос - как прикрепить файл к исходящему письму в сервисах Gmail, Yandex, Rambler и Mail.Ru.

{mosloadposition debug}

Gmail

При создании нового письма в почтовой службе Gmail от компании Google, достаточно нажать на ссылку «Прикрепить файл», а затем найти на своем компьютере нужный файл или архив и дважды щелкнуть по нему мышью.

Имейте в виду, что в e-mail можно вложить только файлы или архивы. Это правило относится не только к Gmail, но и к другим почтовым сервисам. Прикрепить папку к исходящему письму нельзя! Если требуется отправить несколько файлов, их нужно упаковать в один архив, например, формата RAR или ZIP, который затем прикрепить к письму. Также можно приложить каждый файл из папки по отдельности.

Для того чтобы прикрепить следующий файл нажмите ссылку «Прикрепить еще один файл» и проделайте уже знакомые вам действия по выбору файла.

Чтобы отменить прикрепление файла к письму достаточно снять галочку напротив него.

К письмам Gmail можно приложить сколько угодно файлов. Следует лишь помнить, что общий размер письма вместе со всеми прикрепленными файлами не должен превышать 25 Мб.
Также учитывайте, что пересылка исполняемых файлов, например, в формате EXE, сервисом Gmail запрещена. При этом упаковка файлов в архив также не помогает. Однако из любой ситуации есть выход: можно изменить расширение файла, например, с EXE на EX, и сообщить получателю письма, что после сохранения на компьютере файл следует переименовать обратно.

Почта на Yandex

Прикреплять файлы к письмам в почтовой службе Яндекса так же просто. Достаточно нажать на кнопку «Прикрепить файл…» и выбрать нужный файл или архив на компьютере, а затем дважды щелкнуть по нему мышью

К письму можно приложить несколько файлов, каждый раз нажимая кнопку «Прикрепить файл…». При этом следует помнить, что максимальный размер исходящего письма со всеми присоединенными файлами не должен превышать 22 Мб. В противном случае лишние файлы придется удалить.

Но сделать это очень просто - щелкните по иконке с красным крестиком напротив не нужного файла, чтобы открепить его от письма.

В почте Яндекса есть очень интересная опция, которая позволяет загружать файлы на Яндекс.Народ вместо того, чтобы прикреплять их к письму. Если размер прикрепляемого к сообщению файла превышает допустимый, то файл будет загружен на Народ автоматически, а получатель вашего письма увидит ссылку, перейдя по которой сможет скачать данный файл.

При необходимости, вы можете самостоятельно загрузить любой файл на Народ: нажмите на стрелочку возле кнопки «Прикрепить файл» и выберите данный способ пересылки файла. Максимальный размер файла, загружаемого на Яндекс.Народ, составляет 5 Гб.

Почта на Rambler

Почтовый сервис Рамблера предоставляет похожий стандартный для прикрепления файлов к исходящим письмам: вам нужно будет нажать кнопку «Прикрепить файлы», найти и выбрать нужные файлы на диске компьютера.

Вы можете прикрепить к сообщению несколько файлов. Но помните, что их общий размер не должен превышать 20 Мб.
Если же потребуется удалить прикрепленные к письму файлы, достаточно щелкнуть по иконке с красным крестиком напротив наименования удаляемого файла.

Mail.Ru

И, наконец, последний почтовый сервис, который мы сегодня рассмотрим - почтовая служба Mail.Ru. Она, как и Яндекс, позволяет отправлять файлы двумя способами - вложить непосредственно в письмо либо загрузить на Файлы@Mail.Ru. В последнем случае получателю вашего сообщения будет отправлена ссылка для скачивания файла.

Для того чтобы присоединить к письму файл щелкните по кнопке «Прикрепить файлы», а затем выберите на компьютере нужные файлы. Вы можете прикрепить несколько файлов и архивов к письму, нажав кнопку «Прикрепить еще».

Общий размер всех присоединенных к письму файлов не должен превышать 22 Мб. Если же подготовленные к отправке файлы имеют размер более 30 Мб, то их следует загрузить на сервер Файлы@Mail.Ru. Для этого нажмите ссылку «Изменить» и выберите данный способ присоединения файлов - «Загружать все файлы на Файлы@Mail.Ru и присоединять к письму в виде ссылок». В таком случае адресат получит письмо с автоматическим сформированными ссылками для скачивания файлов с сервера.

К каждому исходящему письму может быть присоединено не более 20 файлов. При этом размер каждого файла не должен превышать 1Гб.

Если же вам потребуется удалить файлы из приложения, просто нажмите иконку с красным крестиком напротив наименования удаляемого файла. Он исчезнет из списка.

Итак, мы рассмотрели способы отправки писем с вложенными файлами в различных почтовых сервисах. В работе каждого сервиса есть свои нюансы, поэтому при создании исходящих писем советуем обращать внимание на допустимое количество, объем и формат прикрепляемых к нему файлов.

Специально для Ячайник, Елена Карлтон

{mosloadposition cpanel}

Предположим, вы сформировали архив базы и теперь пытаетесь загрузить его в файловом варианте. Сначала все идет хорошо, но в какой-то момент возникает ошибка:

"Ошибка загрузки информационной базы. В информационную базу загружены не все данные по причине: Ошибка СУБД: Превышен максимально допустимый размер внутреннего файла "D:\1CBASES\NewDB/1Cv8.1CD" "

Я лично потратил ОЧЕНЬ много времени на поиск решения этой проблемы и в итоге нашел его, что позволило нам создать файловую копию базы данных размером 18 Гб и в итоге сэкономило примерно неделю времени (могу в комментариях рассказать, как было дело, но сейчас речь не о том).

Итак, причин возникновения такой ошибки может быть несколько:

1. Размер КАКОЙ-ЛИБО таблицы в базе данных превышает лимит для файловой версии (4 Гб) . Если честно, во избежание подобных эксцессов мы проверяли размеры таблиц базы заранее с помощью обработки " " (или аналогов).
2. Ошибка связана с глюком особенностями платформы, и вызвана определенной спецификой структуры метаданных выгружаемой конфигурации.

С первым случаем все понятно - если базомер показал превышение лимита по каким-то из таблиц базы, то эти таблицы необходимо почистить. Если речь идет о справочнике или непериодическом регистре сведений, то нужно постараться удалить оттуда ненужные элементы/записи. То же самое относится и к "тяжелым" документам с их табличными частями. В первую очередь следует заняться удалением помеченных объектов, конечно.

Регистры накопления - отдельная тема. Размеры таблиц итогов могут превышать размеры таблиц записей регистра, причем зачастую значительно. Иногда может помочь даже простой пересчет итогов.

Регистры остатков могут некорректно (не по всем измерениям) закрываться, что приводит к ОЧЕНЬ значительному и быстрому разрастанию таблиц итогов. Списание "зависших" остатков регистра накопления может при последующем пересчете итогов дать экономию до нескольких Гб, проверено на собственном опыте у "нерадивых" клиентов.))

Что же делать, если каждая таблица вашей базы размером менее 4 Гб, но ошибка все равно возникает?

Это значит, что у вас второй случай - проблемная структура метаданных конфигурации. Вероятнее всего, ошибка возникает на этапе создания индексов.

В двух словах опишу ситуацию в целом, чтобы было понятно, словами Виктора Сосновского из 1С. Ниже цитата с партнерского форума:

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

Нужно узнать, какая именно таблица приводит к ошибке при создании индекса.

Включаем технологический журнал - в папку "С:\Program Files (x86)\1cv82\__НомерВерсииПлатформы__\bin\conf\ " (или аналогичную, __НомерВерсииПлатформы__ подставьте свой) кладем файл logcfg.xml примерно следующего содержания:

Внимательно следим за тем, чтобы каталоги для дампов и логов:

1. Существовали
2. Различались
3. Были доступны для чтения и записи тому пользователю Windows, от лица которого вы запускаете конфигуратор.

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

Первое же вхождение EXCPCNTX в логе в моем случае указало на команду, которая вызвала ошибку: CREATE INDEX _Accum27148_ByDims_TRRRRRRRRRSSR (у вас название индекса будет другое).

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

В первую очередь следует смотреть, какие поля входят в индекс. Как выяснилось, платформа ОЧЕНЬ не любит, когда совокупный размер ключевых полей индекса становится значительным. В частности, она не любит индексировать длинные строки - так, в моем случае в индекс попадало измерение с типом СТРОКА (500) и оно вызывало ошибку. Другой представитель фирмы "1С" высказался на партнерском форуме еще в 2007 году:

"Если длина ключа оказывается близкой к 2К, то начинается резкий рост размера индексов с рядом неприятных последствий. "

И действительно, в 2013 году ничего не изменилось - в подобных случаях наблюдается лавинообразный рост размеров индекса на файловой базе. А когда таблица индекса превышает лимит в 4 Гб, загрузка.DT останавливается с ошибкой.

Лично мне помогло отключить для проблемного измерения флажок "Использование в итогах", т.к. в реальности итоги по нему не требовались. Оно перестало попадать в саму таблицу оборотов и, как следствие, в индекс таблицы оборотов. Есть и другие способы - более строго ограничить размер строки, например. Читал, что некоторым это помогало.

Эти изменения необходимо применить к информационной базе, при этом произойдет реструктуризация вашей таблицы.

Если изменения внесены на SQL-копии базы, то после этого нужно заново выгрузить.DT и попытаться перезагрузить его в файловой версии.

Если SQL-копии нет под рукой, то можно попробовать исправить прямо на вашей недозагруженной файловой копии. После принятия изменений запускайте "Тестирование и исправление" в режиме реструктуризации таблиц базы данных. Индексы будут созданы платформой заново и, можно надеяться, уже без ошибок.

Кому особо не повезло и ошибка вылезла снова - тому следует повторить сначала всю процедуру, начиная с анализа логов. Возможно, проблемная таблица была не одна, или вам не удалось решить проблему с размерами полей, входящих в индекс.

Предположим, вы сформировали архив базы и теперь пытаетесь загрузить его в файловом варианте. Сначала все идет хорошо, но в какой-то момент возникает ошибка:

"Ошибка загрузки информационной базы. В информационную базу загружены не все данные по причине: Ошибка СУБД: Превышен максимально допустимый размер внутреннего файла "D:\1CBASES\NewDB/1Cv8.1CD" "

Я лично потратил ОЧЕНЬ много времени на поиск решения этой проблемы и в итоге нашел его, что позволило нам создать файловую копию базы данных размером 18 Гб и в итоге сэкономило примерно неделю времени (могу в комментариях рассказать, как было дело, но сейчас речь не о том).

Итак, причин возникновения такой ошибки может быть несколько:

1. Размер КАКОЙ-ЛИБО таблицы в базе данных превышает лимит для файловой версии (4 Гб) . Если честно, во избежание подобных эксцессов мы проверяли размеры таблиц базы заранее с помощью обработки " " (или аналогов).
2. Ошибка связана с глюком особенностями платформы, и вызвана определенной спецификой структуры метаданных выгружаемой конфигурации.

С первым случаем все понятно - если базомер показал превышение лимита по каким-то из таблиц базы, то эти таблицы необходимо почистить. Если речь идет о справочнике или непериодическом регистре сведений, то нужно постараться удалить оттуда ненужные элементы/записи. То же самое относится и к "тяжелым" документам с их табличными частями. В первую очередь следует заняться удалением помеченных объектов, конечно.

Регистры накопления - отдельная тема. Размеры таблиц итогов могут превышать размеры таблиц записей регистра, причем зачастую значительно. Иногда может помочь даже простой пересчет итогов.

Регистры остатков могут некорректно (не по всем измерениям) закрываться, что приводит к ОЧЕНЬ значительному и быстрому разрастанию таблиц итогов. Списание "зависших" остатков регистра накопления может при последующем пересчете итогов дать экономию до нескольких Гб, проверено на собственном опыте у "нерадивых" клиентов.))

Что же делать, если каждая таблица вашей базы размером менее 4 Гб, но ошибка все равно возникает?

Это значит, что у вас второй случай - проблемная структура метаданных конфигурации. Вероятнее всего, ошибка возникает на этапе создания индексов.

В двух словах опишу ситуацию в целом, чтобы было понятно, словами Виктора Сосновского из 1С. Ниже цитата с партнерского форума:

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

Нужно узнать, какая именно таблица приводит к ошибке при создании индекса.

Включаем технологический журнал - в папку "С:\Program Files (x86)\1cv82\__НомерВерсииПлатформы__\bin\conf\ " (или аналогичную, __НомерВерсииПлатформы__ подставьте свой) кладем файл logcfg.xml примерно следующего содержания:

Внимательно следим за тем, чтобы каталоги для дампов и логов:

1. Существовали
2. Различались
3. Были доступны для чтения и записи тому пользователю Windows, от лица которого вы запускаете конфигуратор.

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

Первое же вхождение EXCPCNTX в логе в моем случае указало на команду, которая вызвала ошибку: CREATE INDEX _Accum27148_ByDims_TRRRRRRRRRSSR (у вас название индекса будет другое).

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

В первую очередь следует смотреть, какие поля входят в индекс. Как выяснилось, платформа ОЧЕНЬ не любит, когда совокупный размер ключевых полей индекса становится значительным. В частности, она не любит индексировать длинные строки - так, в моем случае в индекс попадало измерение с типом СТРОКА (500) и оно вызывало ошибку. Другой представитель фирмы "1С" высказался на партнерском форуме еще в 2007 году:

"Если длина ключа оказывается близкой к 2К, то начинается резкий рост размера индексов с рядом неприятных последствий. "

И действительно, в 2013 году ничего не изменилось - в подобных случаях наблюдается лавинообразный рост размеров индекса на файловой базе. А когда таблица индекса превышает лимит в 4 Гб, загрузка.DT останавливается с ошибкой.

Лично мне помогло отключить для проблемного измерения флажок "Использование в итогах", т.к. в реальности итоги по нему не требовались. Оно перестало попадать в саму таблицу оборотов и, как следствие, в индекс таблицы оборотов. Есть и другие способы - более строго ограничить размер строки, например. Читал, что некоторым это помогало.

Эти изменения необходимо применить к информационной базе, при этом произойдет реструктуризация вашей таблицы.

Если изменения внесены на SQL-копии базы, то после этого нужно заново выгрузить.DT и попытаться перезагрузить его в файловой версии.

Если SQL-копии нет под рукой, то можно попробовать исправить прямо на вашей недозагруженной файловой копии. После принятия изменений запускайте "Тестирование и исправление" в режиме реструктуризации таблиц базы данных. Индексы будут созданы платформой заново и, можно надеяться, уже без ошибок.

Кому особо не повезло и ошибка вылезла снова - тому следует повторить сначала всю процедуру, начиная с анализа логов. Возможно, проблемная таблица была не одна, или вам не удалось решить проблему с размерами полей, входящих в индекс.

При использовании файлового варианта информационных баз, нередко появляется ошибка «Превышен максимально допустимый размер внутреннего файла», связанная прежде всего с особенностями реализации самого файлового режима. В его составляющую входит 4 файла:

• Файл описания структуры таблицы
• Файл индексов(вынесены из основного файла)
• Файл значений
• Файл записей

Также накладываются ограничения, такие как: максимальный размер внутреннего файла не должен превышать 4 ГБ, длина ключа в индексе не может превышать 1920 байт и наконец, количество полей для индексации не должно превышать 256 полей. Самым главным для нас является ограничение в размере файла 4 ГБ. А как же так? Скажете Вы. Есть файлы базы данных и по 10 и по 12 ГБ. Да все верно- это означает что ни один из внутренних файлов не превысил 4 Гб. Смею Вас огорчить. Все таки максимальный объем базы данных, самого того файла 1Cv8.CD все таки ограничен 16 ГБ по умолчанию(но даже это можно обойти), так как это ограничение адресации журнала файловой системы NTFS(файлы 16Гб не копируются в Windows, так как при сбое чтения/записи на фрагменте который больше этих самых 16Гб ОС не может контролировать целостность файловой системы.)

Для решения данной проблемы необходимо вычислить, какая же именно таблица занимает очень много места. Для этого можно воспользоваться сторонней программной Tool_1CD, которая и позволяет заглянуть внутрь файла 1Cv8.CD, а именно определять размер таблиц, делать выгрузку в XML формат и многое другое.

Для решения необходимо уменьшить размер этой самой таблицы или перевести в SQL вариант. Так как приобрести SQL сервер довольно затратно, опытным путем ищем эту таблицу. Обычно это бывают «тяжелые документы» с большой табличной частью, громоздкие справочники, особенно часто регистры накопления. Прежде всего удалите из базы все помеченные на удаление элементы. Затем сделайте пересчет итогов(если «косяк» в регистре накопления, то иногда помогает). Регистры остатков могут неверно закрываться, что приводит к резкому разрастанию таблиц итогов. Списание «зависших» остатков может освободить до нескольких Гб.

Бывает так, что все таблицы меньше 4 ГБ, но ошибка все равно возникает. Данная ситуация намного сложнее. Здесь кроется проблема в структуре матаданных конфигурации, а именно в индексации. В момент загрузки информационной базы из dt файла первым делом загружаются данные всех таблиц, а уж после — индексы. В какой то момент создания индекса, возникает ошибка и последующие индексы не создаются, что прекращает загрузку и вызывает ошибку. Для того, чтобы узнать какая таблица сбоит при создании индекса- делаем следующее:

• Включаем технологический журнал
• Cоздаем пустой файл ogcfg.xml следующего к примеру содержания

и кладем его в каталог conf, например C:\Program Files\1cv82\8.2.19.130\bin\conf

• проверяем, чтобы логи и файлы создавались и перезапускаем конфигуратор и начинаем загрузку заново. после возникновения ошибки идем в log файл в нашей пвапке C:\log\error, открываем и ищем на каком индексе появилась ошибка.
• Далее при помощи программы Структура хранения таблиц базы данных ищем сам объект метаданных.
• Ну а дальше опытным путем ищем либо длинных реквизит этого объекта, либо свойстве приводящая к сбою построения индекса и продолжаем пробовать, пробовать и пробовать, пока не придем к решению.
• После удачных манипуляций телаем тестирование и исправление. В результате чего все индексы перестроятся заново и база будет полностью работоспособна. Удачи!