Как одолеть ограничение в 2ГБ?
Kernel3x не дает результата

Перейти на SQL

(1) А толку?
(0) Переходи на 8.3

(0)
https://forum.infostart.ru/forum9/topic57211/

(2) ну, на скуль можно и бесплатно перейти, если вписаться в ограничения :)

Связка 1С:Предприятие 7.7 + MS SQL Server 2008 R2 + Microsoft Windows Server 2012 R2
?

(0) Конфа какая?

(1) Помнится, в 2005 году один инициативный админ перевел на SQL базу с компонентой "Расчёт", и все перестало работать. База была небольшая. Разбираться никому не хотелось, дали админу по шапке и заставили вернуть обратно.

И да "Переходи на 8.3" +1

(7) не, ну проблема была исключительно в скуле, да?

(9) Не знаю, врать не буду.

Но склоняюсь к тому, что проблема была в одном инициативном дураке.

(9) Я просто хотел сказать, что перевод на SQL - не гарантия того, что проблема у автора исключительно в размере базы.

(11) хоспаде, проблема 2гб решалась скулем тогда. Сейчас ДенисЧ скорее прав. Лучше перейти на снеговика

(6) ТиС 9.2
---
Сейчас ошибка:

codebase error
Error #: -120
Writing to File
RG328.DBF

(12) 2гб чего? Файла бд или оперативки?

(13) >RG328.DBF
Думаю много незакрытого в регистре

Свертку бы вам сделать и дальше работать
Возьми чистую базу без регистров (только SC) и перенеси остатки

(13) Тогда в скуль )))

(15)+ Ну или переходить на УТ или КА рекомендую
Лучше на КА чтобы не иметь проблем с синхронизацией с БП

Незакрытые регистры разобраться что не закрывается и почему. Если в принципе вопрос не решается то в одной конторе создал 1 документ, что закрывает такие косяки. обработку которая создала и заполнила этот документ на последнее число каждого месяца от регистра 200 кб осталось.

(15) достаточно зафиксировать остатки на, скажем, начало 2020, закрыв регистр, и удалив ненужные итоги - и еще лет 10 работать можно

RG328.DBF что за регистр и какие у него измерения

Переходить с клюшек на снеговика не дождавшись 2038 года? Это кощунство

(20) ПартииНаличие жеж.

(21) с 7.7 - только на 8.8!

(22) я по русским конфам не настолько спец чтобы помнить по номеру что за регистр

(14) файл RG328.DBF регистр остатков

(24) ну прошу пардону!©
просто настолько заезженый вопрос по этому регистру, что уже автоматом извстен и регистр, и решение...

(26) был заезжен лет 15 назад :)

Какой размер RА328.DBF. при нормальном учете RG328.DBF должен быть в несколько раза меньше.

Переход на SQL очевиден, а в данном случае как можно обойти ограничение в ГБ для DBF?

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

Измерения ресурсы регистра приведи. Построй отчет по всем измерениям и ресурсам. смотри его.
Если товар 1 остаток 0 а сумма 0,20 коп. то нужно посоздавать документы на конец месяца и все товары остаток которых =0 а сумма неравна 0 списать сумму в 0.
Или товар числится на одной фирме а продается от другой. в итоге на фирме А висит -1 шт. А на фирме Б +1 шт. и так милион записей с начала существования базы. тогда нужно смотреть свернутый остаток по товару и если он равен 0 то обнулять остатки по фирмам. и т.д. привести учет к нормальному виду и регистр сам сдуется до нормального размера.

(31) Измерения: Фирма, Номенклатура, Склад, ЦенаПрод
Ресурсы: Количество

ЦенаПрод - отсюда копай.. У тебя там розница, штолле?

(33) у @Епрст ж была обработина которая показывала незакрытые регистры?

Ёпрст

(34) Эк ты ИТС-то обозвал...
Там есть такое... regprint называется...

Думал его поделка

На самом деле проблемы 2 гигобайта на файл нет, это старые ограничения из FAT.
Сейчас такого наверное нигде не найдешь уже.
Я обслуживал базы где DBFки были более трех гигобайт и все прекрасно работало.

Мне кажется вы столкнулись с ограничением индекса в DFB файле.
Индекс - число с (не помню какой разрядностью, кажется 32 бита), документы в регистр пишут, на каждую запись ставиться индекс, и очередной тупо не влазит в эти 32 бита

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

(37) Не, у него есть специализированная, но её искать надо...

(38) блин, точно!
(0) Какая ФС?

(38) Дополню
Упаковку + переиндексацию, а не просто переиндексацию
потому что "удаленные" записи в файле физически остаются и занимают индекс. Заодно и размер уменьшится.

д/dbf: kernel3x
д/sql(new): solution7

А у меня усё есть:
Для увеличения памяти 1С больше 2Gb: 4Gb Patch NTCore https://ntcore.com/?page_id=371
Для загрузки и выгрузки dt больше 2Gb: ConfigSpy от АЛьФ http://www.dorex.pro/?projects&configspy&download
Для работы 1C с файлами dbf больше 2Gb: dbeng32 от Wirth https://cloud.mail.ru/public/3mVX/4trK45on8

З.Ы. все равно резать базу придется, не сейчас но придется...

(30) ВыбратьПодчиненные - добавляешь даты, и задумчивость пропадает. а если заменить функцией - получаешь сахар в виде фильтрации по проведенности/виду подчиненных/еще там чему-то
(31) удаление нулевых остатков очень просто делается на той же 1с...
(43) "всё бы им, херургам, резать... попрыгай - сами отвалятся"©

(27) ну если ТС еще и в гугле забанен, тады да...

(44) "попрыгай - сами отвалятся"
Это что за политика в тематической ветке? )))

РГ328 - итоги по регистру партий. регистр тотально незакрыт. скорее всего присутствует несколько контор (типа ИП и ООО которые торгуют общими остатками с контролем "по компании в целом"). В нормальном учете почти всегда приходы партий БОЛЬШИЕ и много мелких движенйи по расходу партий. то есть регистра RA328 д.б. намного ощутимо больше чем РГ. (например, у меня RG328 = 57МБ, RA328 670Мб (учет партий по среднему) - это правильное соотношение размеров)

https://infostart.ru/public/180018/ - очистка нулевых итогов

(44) Так я же не хирург! Я терапевт! Ну отвалятся... но ведь не сразу же?

(0) Для начала уменьшить в регистре размерность числовых ресурсов. Вряд ли по факту используется Число.15.2
Плохо нет нормального поиска на мисте - дал бы ссылку на тему где это обсуждалось.

Недавно восстанавливал файл РГ328. Вроде он был больше 2 ГБ. Но после аккуратного пересчета итогов по движениям регистра партий он стал 1.3 ГБ

(51)+ Сначала его вообще снести прищлось

(52) В базе сейчас периодичность сохранения остатков установлена 5 дней и 7 лет в работе. Пересчет итого затянется на несколько дней)

(48) Где бы такую обработку попробовать?)

(52) серпом...

(5) Нормально, что не так?
А так, начинайте Сворачивать базу, 7.7 по инструкции сворачивают ;)


https://profbuh8.ru/2016/08/svertka-bazyi-1s-7-7/

(54) Дык ты хоть что то для этого сделай. слать на деревню дедушке?

(57) Киньте и мне плиз. Любопытно глянуть. ПОчта указана в профиле

(58)+ Плиз это пожалуйста )

(57) можно и мне, пожалуйста)

Готовлюсь резать ТиС 7.7 10 Гб. Буду делать частями. Итоги по всем регистрам считаются за 15 минут. Самая долгая часть - удаление документов. Еще долго пересчитывать итоги, поэтому удаляю RG*, перекидываю ТА в начало и в конец, занимает час. Буду, наверное, резать год, по месяцам. "Окно" монопольной работы - 12 часов.

(57) у меня RG328.DBF - размер 2146819604 (107,3%), записей 13587463 (81%)
в SQL-е тоже ограничение по записям?

(62) в бесплатном скуле ограничение на объем БД

и использование ядер, и ещё там что-то

(62) RG пухнет сам, как на дрожжах. Эффективно сделать как в (61). Попробуй на копии, время работы программиста ~ 2 мин.

(25) чего вы там продаете, если у вас остатки на 2Г... приводи учет в порядок, чисти и обрезай базу, с таким подходом вы и скуль засрете...

(61) я уже писал товарищу из (51) в его теме, как надо делать... чтоб без всякой монопольщины и т.п. Правда, на файловой переиндексироваться придется, поэтому "почти без монопольщины". а на сиквеле - вполне можно делать в базе, работающей 24*7
(65) "сами" даже кошки не родятся...

(61) у меня такая база режется с перекурами без предварительного плана часа за два неторопливо. Универсальным двигателем регистров загоняем регистры на дату обрезки. ТА на начало. Штатно помечаем документы на удаление (с транзакциями). ТА на перед документами обрезки. Удаляем РГ. Перегоняем ТА на сейчас. Удаляем штатно что может удалиться.
Примерно так

(65) "RG пухнет сам, как на дрожжах."
не должно быть так, недокручено что-то...

(68) неплохо, попробую так, замерю время выполнения.

(68) Попробовал, быстро, буду резать сразу год. Спасибо, коллега!

(71) https://pp.userapi.com/c621931/v621931675/397f0/CuL1hRFf8u8.jpg

(71) (72) на что только люди не идут, лишь бы не работать :-)

Пытаюсь сделать упаковку нулевых итогов регистров для файлового варианта под Win212r2 server.
ДБ = СоздатьОбъект("OLEDBData");
: Неудачная попытка создания объекта (OLEDBData)
Что установить необходимо?

(74) https://infostart.ru/public/180018/

(74) на мыле

(75) (76) Спасибо! Пробую)

(76) установил, перегрузил комп, но сообщение об ошибке присутствует.
?

(13) Упаковку БД через конфигуратор сделай https://prnt.sc/15j4ohn

(74) оно тебе не поможет. При не закрытом регистре, это мёртвому припарки. Выигрыш не больше пары %

(79) упаковка не удалит ему нулевые итоги, тока удаленные записи очистит, коих там почти нет.

Для начала, нужно выяснить, почему регистр не закрывается. Потом ужо..удалить лишнюю аналитику и пересчитать итоги, и размер rg будет пара десятка метров, а не 2 гига

(81) не закрывается, потому что задним числом производят изменения в документе поступления. Убедить в том, что это не правильно, бесполезно. Базе уже примерно 7 лет. Нужно каким то образом избавиться от нулевых итогов...

(82) Это вообще ни на что не влияет

Оценить количество записей с нулевыми итогами можно простым селектом. Их там будет..мало.

очень мало.

ra этого регистра, какой размер имеет ?

(86) RA328.DBF - 41 МБ

(86) RG328.DBF - 2,1 ГБ
Период сохранения остатков: 5 дней

(87) да уж..феерический пиз..ц

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

(87) при таком размере RA размер RG мегабайт 4-8 д.б.

(88) и че ? У нас всегда был период хранения 5 дней.
Итоги пересчитывались влёт все, за любой период, штатно.

возможно несолько фирм с отключенным контролем остатков или контроль в целом по компании. Интерккампани не делалось никогда.

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

(92) или какой-то умник добавил новое измерение, которое только в расходе заполняет

Хотя с такими измерениями
Фирма, Номенклатура, Склад, ЦенаПрод...
ЦенаПрод - вот тут, 99.9% ошибка

иначе, разве что приход с одной фирмой, расход с пустой или с другой.

Посмотреть 2 секунды, открыв движения регистра у прихода и расхода.

(92) фирма одна, а вот по партиям списываться может правильно, а если потом эту партию (поступление) удалить или изменить без проведения последующих зависящих документов?

(95) штатно все норм делается. для оптового склада ЦенаПрод везде = 0. для розницы - установлена строго. Но засада может быт здесь - олухи царя небесного при вкручивании в розницу скидок и прочего делают неправильно и тянут хвостами незакрытые партии по ценапрод.

(98) в (32) нет партий.
Или ты огласил не все измерения ? :))

(98) ну сделай блин ТИПОВОЙ отчет с максимально возможным количеством группировок без фильтров Меню-Отчеты-Ведомость по партиям и смотри что незакрыто, будет видно сразу.

Ну или саму табличку rg открыть и посмотреть глазками, там тоже сразу видно, по какому измерению не закрыто

(100) еще есть Реквизиты: Внутреннее (число)

для полного отчета по всем измерениям (такового может и не оказаться если вдруг) - заюзать или штатный "универсальный отчет по регистру" или https://infostart.ru/public/14794/

(103) вообще-то это ты приводишь скорее всего для регистра ОСТАТКИТМЦ. а номер 328 - это регистр "ПартииНаличие"

в (32)+(1-03) приведена структура типового Регистр.ОстаткиТМЦ, а речь идет о "328" - это другой регистр (Партии) с другим набором измерений

(106) Регистр: ПартииНаличие

Измерения:
Фирма
МОЛ
Номенклатура
СтатусПартии
Партия
ДатаПартии
ЦенаПрод

Ресурсы:
Количество
СуммаУпр
СуммаРуб
СуммаБезНДС
СуммаПлат

(107) я знаю.

выкладывай уже свою базу на файлопомойку целиком, нужны *.dbf и *.md, всё

(109) что, на снеговике - скучно? ;-)

(107) :)
Реквизиты
КодОперации
ПродСтоимость
Выручка

(111) да, как его теперь закрывать?

(112) :) епрст прав - выложи базу, посмотрим что можно почикать

(113) хватит и RG328

(114) https://drive.google.com/file/d/12Ap45kafKFhGpsUupuXO6OVzWKVYYAC-/view?usp=sharing

Так может по движениям восстановить RG328  и он наверняка будет меньше и создастся. Недавно так делал.
Правда файл был чуть меньше 2 ГБ но все равно индексироваться не хотел.
Перезаполнил его по RA328 и вроде все норм стало - файл RG328 стал 1.3 ГБ

(116) удалить его и перепровести документы? по времени сколько выйдет?

(117) с учетом, что периодичность сохранения остатков установлена 5 дней

(117) Документы перепроводить не надо никакие. Но если 5 дней то возможно будет долго пересчитывать

(119) пересчитать на копии, подменить, пересчитать последние 5 дней дерганьем ТА

(120) с регистром в 2 ГБ? Запускал когда то, с ошибкой вылетало

(121) Размер РА какой?

(122) 41 МБ сейчас

(122) выше писал, 47 Мб

(121) файл итогов убить нахрен. далее - как написано. посмотреть что получится.

сделать копию базы.
сдвинуть ТА на самый первый документ.
удалить RG328.*
на псоледнем документе текущем в сейчас - правой мышью - установить ТА на документ - в появившемяс окошке НИЧЕГО ГАЛКАМИ НЕ ОТМЕЧАТЬ, все выключить (то есть без перепроведения документов).
прога начнет сдвигать ТА от первого дока на сейчас, ПЕРЕСЧИТЫВАЯ ИТОГИ и более ничего не делая (документы не перепроводятся!).
.
ждать.
.
когда закончится (если закончится) - смотреть что получилось.
скорее всего получилось примерно как было и раньше.
плюс есть возможность не дождаться можжет молотить и сутик и двое и больше в самом худшем случае.
.
индикатором является продолжительность открытия нового периода.

(125) Ну не знаю как можно получить из Ра в 47 МБ РГ в 2 ГБ

(127) наверное ТС очень старался.

(128) Да все бывает - плюс на минус вот и итог появился

(129) могло еще так быть, например, поработали чуток, потом поняли что партионка нахрен не нужна, отключили ее в коде. а ранее наработаннное осталось незакрытым и начало тянуться . все 10 лет что работает база. вот и дотянулось.

автор смотри чего я тебе нашел - https://ru.wikipedia.org/wiki/Виргинский_опоссум
"При серьёзной опасности опоссумы «притворяются» мёртвыми. Сильно напуганный опоссум входит в каталептическое состояние, падает на землю, сворачиваясь клубком и поджимая конечности; на прикосновения он не реагирует, а лежит на боку с приоткрытой пастью и вывалившимся языком. При этом мышцы его расслабляются, а анальные железы выделяют зловонный зеленоватый секрет." (с)
https://scontent.fiev21-1.fna.fbcdn.net/v/t1.6435-9/166012492_1903418776477108_4023971221029157740_n.jpg?_nc_cat=103&ccb=1-3&_nc_sid=825194&_nc_ohc=RvA1JPzv71QAX_3Con5&_nc_ht=scontent.fiev21-1.fna&oh=42292f0b65277301338f1d96ea607c6e&oe=60CF2645

(131) спасибо, поржал! ;-)

Короче, скучно тут с вами, пойду на выставку смотаюсь RosUpak

(127) Был у меня такой клиент. Выгрузка базы - 50 мегабайт, MDF - 10 Гигабайт. Пересчет итогов за 6 лет, запущенный из спортивного интереса на мощном компе, - я сбросил на второй неделе.
А всего-то один регистр на 7 измерений, в которых последние 2 - должны были быть реквизитами, но кривые руки сына маминой подруги, на коленке подрихтовавшего чужую нетленку, сделали из регистра остатков огромную кучу мусора. Ведь разница между "Измерением" и "Реквизитом" несущественная). Номенклатура тогда была под 150 тысяч.
НА каждом (!) реквизите при этом стояли галки "Отбор движений" и "Отбор итогов". А на регистре - "Быстрая обработка движений".
Ну и чтобы это всё быстрее работало - периодичность сохранения остатков была установлена в "Пять дней".
Оптимизаторы, блин...
Берёг я потом эту базу как экспонат для Кунсткамеры.

Я это всё к чему - может у ТС там не только регистр не закрывается (хотя это и наиболее вероятно), но и периодичность сохранения остатков прооптимизирована.

Ну посмотрел dbf из (115) - куча пустых партий с минусовым остатком по количеству и нулями по суммам.
И с чего такой регистр должен свертываться?
Возможно из старой и кривой свертки они ползут...
Много зависших партий от 2015 года, видимо по той же причине.
Ну а так СуммаУпр всегда равна СуммаРуб, можно ее удалить.
ДатаПартии в этом регистре вообще не нужна, ее можно из самой партии вытянуть.

(135) Короче,.. Овчинка выделки не стоит? или как то можно позакрывать?

(136) двигателем регистров закрой старые партии

(137) на начало каждого периода или последнего?

(135) ДатаПартии в типовой ТиС не эквивалентна дате документа партии. В некоторых местах чуть по другому делается если посмотреть. Но не думаю что это принципиально. если надо будут более развернуто пояснения - это отдельно...

(138) правильнее закрывать всё на конец каждого периода, тогда этот закрытй итог не будет дальше тянутся... вопрос в том как определить что закрывать.

(115) кинь ra этого регистра

(141) https://drive.google.com/file/d/1_hKUUppAbardCDkyr8eOlhFN0k0k6uAg/view?usp=sharing

галактика замерла в ожиданиии...

(143) )))

(142) У тебя
1.мол и цена прод можно выкинуть, как и цена упр (в плане производительности)

2. есть 2 возврата от покупателя с партиями от  28.06.2019 и 02.06.2020 по другой фирме, по которой не было расхода

но, там записей в rg не так и много, ибо провели их мае этого года.

3.ща.. занят пока.
Основной затык будет в партиях/датепартии/статусе партии. ща скажу, где

(142) читаем (145) и отвечаем на вопрос: а зачем ты соврамши что учет ведется по одной фирме?

При таком колве движений по партиям - периодичность в 5 дней - нафиг не нужна. выставить периодичность итого = 1 месяц, размер КП после пересчета итогов упадет раза в 4-6.

Есть приход 07.09.2017 который сделал 12 записей (12 товаров в нём) с отличным статусом партии, и который породил 3264 записей в итогах (ибо списания с таким статусом партии нема).

но это пока не всё.

При таком РА и таком РГ и даже при периодичности в 5 дней = все равно очень все несбалансировано.
Скорее всего проводили сделки, а потому удаляли приходы и/или работали исключительно как печмаш без контроля остатков. Поэтому в коде отрубить нафиг формирование движений по партиям (там немного мест, забыть про партии совсем и работать дальше как работали.

(146) Добавлено фирм несколько, но фактически используется только одна

(149) Так и есть! Пользователям делают правки в документах задним число, с изменением цен, количества и др.

Короче, основной трабл, в валюте.
У вас не верный пересчет, либо балуетесь курсами и куева туча записей оставляет куеву тучу останков, ибо суммаУпр<> СуммаРуб.

Валюта упр и бух учета какая ?

(153) UAH изначально было установлено(

(150) фактически - несколько. Епрст показал.

(154) поэтому, при скачке курса массово меняем цены согласно нового курса

(156) это никак не относится к кривости партий

(155) в справочнике несколько, а в документах одна фирма... Возможно проскользнула в проведении другая фирма, но не массово

нужен ли валютный учет? то есть себестоимость и финрезультат в разрезе двух валют? если нет - то валюту учета установить такую же как нацвалюту. прибить все РГ. отключить контроль остатков (перевсти периодичность итогов на месяц) и полностью перепровести базу. вернуть контроль остатков как было (периодичность оставить месяц)

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

(158) похрен. либо да либо нет. "не массово" - это самоуспокоение, ведет к тому что на это забивают и имеем то что имеем.

(158) в справочнике фирм пометить на удаление ВСЕ ФИРМЫ кроме ОДНОЙ ИСПОЛЬЗУЕМОЙ.
Удалить шттано. Апосмотреть что из фирм осталось неудаленным. курить бамбук и много думать.

На вот, наглядненько:

http://pics.rsh.ru/img/_7edz6jfw.png

Вы покупаете с одной суммой, списываете с другой в СуммаРуб у вас осталось 5 копеек.
Эти пять копеек на остатке, теперь с 16 года в каждом периоде.
Таких записей в ra 17 тыр с копейками. Делайте выводов, сколько записей будет в rg, не удивительно, что он распух с геометрической прогрессией.

(156)
Короче, установить валюту упр и бух учета одинаковой.
Сделать тупо
update ra328
set sp343 = sp421

Прибить rg328.dbf, rg328.cdx,ra328.cdx

Зайти монопольно, сделать пересчет итогов, сдвинув ТА на первый документ и обратно, на последний.
Усё.

Наслаждяться, кушать печенки.

Я понял, спасибо, сейчас буду делать)

(166) это все можно было увидеть типовым отчетом "Ведомость по партиям", но вы забили болт на мои рекомендации и отвлекли такого уважаемого спеца как Епрст на полную хрень.
.
Ёпрст не признается, но ночами он тихо плачет в подушку и тоскует по клюшкам.
Поэтом для ТС расстрел отменяется...

ну и исправить (148)

(166) я бы всетаки сдвинул периодичность итогов на "месяц"...

(167) не, я не такой..

(169) не надо. 5 дней - идеально

(170) такой, такой... иначе че ты оправдываешься ;-)

(171) ну, м.б....
5 дней когда инфы по движениям настолько много, что это имело бы смысл. При таком объеме движений (40Мб) за НЕСКОЛЬКО ЛЕТ, как минимум 5 (с 2016) - 5 дней имхо ну совсем лишнее.

Нет. При 5 дней - самый быстрый режим работы.
Мгновенная запись движений, мгновенный расчет остатков (в том числе. сводных). Мгновенные штатные отчеты с коност

Автору, при желании, можно выкинуть измерения
фирма/мол/ценаПрод/датапартии/статуспартии
ресурсы валютаупр/суммаплат

и.. размер ra (он и так смешной) будет еще меньше
+порезать числовые реквизиты (16.2 сделать, 8.2, напрмер)

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

(174) это понятно. я как раз говорю, что это м.б. при том объеме движений как у ТС совершенно некритично (хоть и быстро).

ДатаПартии используется при расчете ФИФО. И отличается от даты документа при регистрации возвратов.

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

ТС напиши потом что в итоге получилось-то... по размерам...