Попробуй это.
IF OBJECT_ID('tempdb..#Production') IS NOT NULL DROP TABLE #Production
IF OBJECT_ID('tempdb..#Bought') IS NOT NULL DROP TABLE #Bought
CREATE table #Production(R_NO int,ProductionDate datetime,ProductionAmount float)
CREATE table #Bought(R_NO int,Boughtdate datetime,Boughtamount float)
insert into #Production(ProductionDate,ProductionAmount,R_NO)
select p.date ProductionDate,sum(Amount) ProductionAmount,row_number()over (order by p.date) R_NO
from Production P
join Sales s on p.date=S.date-1
where orhsysid=1
group by p.date
declare @loop int,@ProdDate datetime
select @loop =max(R_NO) from #Production
while (1<=@loop)
begin
select @ProdDate=ProductionDate from #Production where r_no=@loop
insert into #Bought(Boughtdate,Boughtamount,R_NO)
select Date,Sum(Amount),@loop R_NO from Bought where date=(
select max(date) from bought B
where B.Date<@ProdDate)
group by Date
set @loop=@loop-1
end
select ProductionDate,ProductionAmount,Boughtdate,Boughtamount from #Bought B
join #Production p on B.R_NO=P.R_NO
Существует несколько опций, и иногда полезно их сочетание:
Подробная информация о различные варианты:
Автоматическая установка Инструменты для автоматизации установки и настройки различных сервисов, инструментов и файлов конфигурации рабочей станции:
Образы дисков Затем, конечно, есть также инструменты создания образов дисков для хранения образа сконфигурированного хоста, так что его можно восстановить на другом хосте. Как и в случае с виртуализацией, это особенно хорошо для тестовых коробок, поскольку их легко восстановить. Постоянное обновление информации по-прежнему остается проблемой - стоит ли создавать новые образы только для распространения изменений в файле конфигурации?
Виртуализация - это еще один вариант, например, создание копий Xen, VirtualPC или Образ VMWare для создания новых хостов. Это особенно полезно с блоками тестов, поскольку независимо от того, какой беспорядок создает тест, вы можете легко восстановить его в чистом известном состоянии. Как и в случае с инструментами для создания образов дисков, поддержание актуальности хостов требует больше ручных действий и бдительности, чем при использовании автоматического инструмента установки / настройки.
Контроль исходного кода После того, как вы установили / сконфигурировали необходимые инструменты, сборка должна заключаться в проверке того, что нужно из репозитория исходного кода и его построении.
В настоящее время я использую комбинацию вышеперечисленного, чтобы автоматизировать процесс следующим образом:
One important point is to set up your projects in source control such that you can immediately build, deploy and run after checkout.
That means you should also checkin helper infrastructure, such as Makefiles, ant buildfiles etc., and settings for the tools, such as IDE project files.
That should take care of the setup hassle for individual projects.
For the basic machine setup, you could use a standard image. Another option is to use your platform's tools to automate installation. Under Linux, you could create a meta-package that depends on all the packages you need. Under Windows, a similar thing should be possible using MSI or the like.
Edit:
Ideally, instead of checking in helper infrastructure, you check in the information that allows the build to generate the helper infrastructure. This is the approach taken by e.g. the GNU build system (autotools etc.), or by Maven. This is even more elegant, because you can (theoretically) generate infrastructure for any (supported) build environment, thus you are not bound to e.g. one specific IDE, and settings in the helper infrastructure (paths etc.) don't need to duplicate the main project settings.
However, this also a more complex approach, so if you can't get it to work, I believe checking in stuff like IDE files directly is acceptable.
если вы используете версию linux, вы, вероятно, имеете систему управления пакетами: думает .rpm для fedora / redhat или .deb для ubuntu / debian. многие из описанных вами вещей уже имеют доступные пакеты: svn, eclipse и т. д. вы можете свернуть свои собственные пакеты для программного обеспечения, специфичного для компании, создать репозиторий (возможно, доступный только в локальной сети), и тогда ваши настройки могут быть сокращены до одного bash-скрипт, который добавит репозиторий компании в /etc/apt/sources.list (debian / ubuntu), а затем вызовет команду наподобие
/home/newhire$ apt-get update && apt-get install some complete package list
, вы можете использовать buildbot , чтобы затем автоматизировать обычные сборки для пакетов компании которые часто меняются.
Если вы используете машины в стандартной конфигурации, вы можете создать образ диска с новой, идеально сконфигурированной установкой - это очень популярный подход во многих корпорациях (и не только для разработчиков). Если вам нужны отдельно сконфигурированные ОС, вы можете tar-bz2 всех добавленных и измененных файлов, как только сконфигурированная ОС будет превращена в желаемую настройку, и просто распаковать ее как root, чтобы создать желаемую среду с нуля.
Всегда есть возможность использовать виртуальные машины (см., Например, VMWare Player ). Создайте одну среду и скопируйте ее для каждого нового сотрудника с минимальной необходимой конфигурацией.
Используйте puppet для настройки среды разработки и производства. Использование первоклассной системы автоматизации - единственный способ масштабирования ваших операций.
Мне нравится использовать Virtual PC или VMware для виртуализации среды разработки. Это обеспечивает стандартную «среду разработки», которая может использоваться разработчиками. Вам не нужно беспокоиться о программном обеспечении, которое пользователь может добавить в свою систему, что может конфликтовать с вашей средой разработки. Это также дает мне возможность работать с двумя проектами, где среды разработки не могут быть одновременно в одной системе (используя две разные версии базовой технологии).
На прежнем месте у нас было все (и я имею в виду ВСЕ) в SCM (прозрачный, затем SVN). Когда новый разработчик может войти, они установили ClearCase | SVN и высосали репозиторий. Это также обрабатывает случай, когда вам нужно обновить конкретную библиотеку lib / tool, поскольку вы можете просто попросить команды разработчиков обновить свою среду.
Для этого мы использовали два репозитория, поэтому код и tools / config жили в разных местах.