For the first time:

• It's necessary to setup sql alises for the first time. You can use SQL Server Configuration Manager from SQL Server Management studio (SSMS) - native client configuration - both 64bit andd 32bit. But SSMS is huge beast. You can use small windows utility - cliconfg.exe. \Windows\System32\cliconfg.exe for 32bit aliases, \Windows\SysWOW64\cliconfg.exe for 64bit aliases. It's necessary setup both. Alieses are on wiki - SQL_2, SQL_NEW_2012.
• Setup local sql server express, it's enough version 2012. It's necessary, because modeling deployment script uses local server for generating models.

Each customer has own environment - e.g. sql server connections - and configuration. Before work, it's necessary to setup environment configuration for these particular customer.

• Go to directory for particular customer and run script for environment e.g. project Configuration/Agrofert/Activate_AGROFERT_TEST.cmd, it setups the connections strings, web configs, app config and other things.
• Don't commit these changes in Configuration dir!

There is database first approach.

• First prepare data changes - update scripts for sql structures, stored procedures, views …
• Generate changes into models
• Table names are according particular module, and customers e.g. DDDiaryReportItem - item for DailyReport

Change data

• increment update number in http://10.0.2.27/doku.php?id=protank_dynamics:pd_databaze
• create update scripts, stored procedures, etc id DatabaseXX directory e.g. DatabaseDD, be aware of numbers in update scripts
• some data - mostly enumarations are in InitData xml files, these are inserted into db when db is deployed, update it if necessary

Apply db changes into model and also into database local database

There are many 'databases'. Each 'database' has own database context in generated C# ORM models. Each such database and context has own directory e.g. DatabaseDD for data which are responsible for daily reports. It's possible that some database entities are in more such contexts. E.g. vehicles are in many databases. It's also possible include one context into another. There is DatabaseCore and most of other databases includes this 'core'.

When we made some changes in database table, stored procedure, view, which are in many 'databases', it's necessary to apply these changes to all these contexts and database classes.

Apply db changes:

• $ cd PD/Application/DatabaseScripts/DeployAndModelGeneration
• $ cmd /c LOCAL_SVN_DD.cmd - 'DD' is label for subject which is changed e.g. changes in DatabaseDD, it uses local sql server express for underlying database and makes the changes in model classes according this database.
• sometimes is possible to generate model form e.g DatabaseREP changes into e.g. Global database context/classes. Simple make the changes in DatabaseREP directory and deploy model via LOCAL_SVN_GLOBAL.cmd, because GLOBAL context contains all other particular module definitions - see localhost_GLOBAL_svn.dcfg for configuration.

Classes are generate according dcfg configurations via sqlmetal Microsoft tool.

deploy db changes to particular SQL server (testing, production):

• $ cd PD/Application/DatabaseScripts/DeployConfig
• $ DatabaseDeployer.exe RSD_ISUD_TEST_OLD.dcfg - or any other dcfg file for particular sql server

Changes in database structure are made through update scripts. These are stored in db tables 'upgrades' tables e.g. 'DatabaseUpgrade' for core tables, KADatabaseUpgrade for database upgrades for KA database modules etc. These tables store information about every upgrade script and when it was called. When new database deployement is started, only these update scripts which aren't in these 'upgrades' tables are processed.

Some customers has very special database setup, see Customers paragraph.

Online Data

There is special fetching process in code. Sometimes it's necessary to add columns into online data database from the OnlineDataColumns table, it's processed via stored procedures

  exec CreateOnlineDataColumn 'CentralBroom'
  exec CreateOnlineDataColumn 'LeftBroom'

It's recommended to use transactions for this execs. Each customer has own onlinedata database.

object and tables

* daily report - stazka - DDDailyReport in db * containers - nádoby - PLAContainersView in DB, many tables, PLAContainersView.cs in Application * defects - závady

ISUD - Old server from VPN Access Manager shrewsoft, only one session is possibe, new server - RSD via certificate, via Cisco AnyConnect. Use special 'RSD' like configuration scripts.

OLO - nothing special

AVE - no bigint is used, special branch - support/not_bigint or similar. Access - nothing special, but there is bad IP address in connection string - necessary to copy correct from dbmouse connection settings - 93.185.96.62,1434

SUSHK - nothig special

SD - has some import from SAP. See Import_SD_SAP_Step_2.proc.sql procedure. This procedure uses special ``SD_IMPORT`` like database name, which is replaced via database deployment definition in e.g. SD_TEST.dcfg. Some of imports from SD are also make via xml transformations and DbMouse design diagrams.

features

• add feature into Application/PSASWeb/FeaturesAll.ftr, will be visible for all applications
• add feature into particular project, e.g. Application/Configuration/isud/features.ftr