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.

Be aware, that in some cases e.g. for new customer, when customer needs some new modules e.g. all particular update scripts can be applied. So when we remove some column it's necessary to check if this one isn't used in some old update scripts.

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

OnlineData, OnlineDataProcessed

OnlineData and OnlineDataProcessed are special tables for data processing. Important column is ROM. It defines observed “unit” which can send online data - table dbUnit.

Showing online data processed for particular vehicle - ROM.

select * from OnlineDataProcessed
where ROM = '352094087747884' and date > '2018-10-01' and date < '2018-10-10'

It's necessary to specify minimal date interval, because table is huge and queries can timeout.

Important table, columns:

• OnlineDataProcessed.ID_ONLINE_DATA_ERROR_TYPE must be not NULL
• OnlineDataProcessed.ID_VEHICLE must be filled. If ins't filled, it means that vehicle was imported later then first online data was arrived.
• DbUnit - it's table for ROMs, it defines which OnlineDataSource is used for particular ROM.
• VehicleUnit - relation table between unit and vehicle.

Copying data from one onlinedata database to another, see more information on raltra wiki

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

Builds are on VSTS in tab “Builds and releases”. Error in builds are mostly linked into task with “link” icon.

Deploy to particular customer:

• Go to VSTS tab “Builds and releases” → “Builds” → “Build Definitions” → “PD1 Build Autodeployable” (click on this)
• Click on button “Queue new build” → dialog → fill your branch and fill customer e.g. avecz
• It will start process for building new package e.g. release for particular branch
• Wait some time, release will be created
• Go to “releases” page, you will se e.g. “Release-365” for our branch.
• Click on this release, you will see list of environments, click on “Action” column - “…” for particular row for customer/environment for deploy. Deployment process will be started after some time. You can se progress on “Logs” tab. Deployment process are serialized in queue. Result of deployment is visible after some time on environment tab after some time.

Reports are based on DevExpress reports with extension in Visual Studio. Reports when you click on report file e.g. ReportUserRights.cs. Dialog designer will be opened. Set No to question about converting binding to expression. All report components, including data bindings, detail bond e.g. are pulled from the Toolbox Palet in designer into main report.

Each time, we make some changes in report project, doesn't matter if in code or design. It's necessary to rebuild the particular report project, because each report is in own dll.

Data binding

Each report has own data connection. Mostly it's via dynamic binding. Opens the Visual Studio main menu XtraReports → Report Explorer. There is e.g. Components → binding1. Click right on binding1 and select Properties. You will see dynamic binding with BindingSource class, where property binding1.DataSource is particular class. Correct binding must be edited directly in code with line e.g. this.ManualSource.DataSource = typeof(ReportCreator.DataRow);. And then particular project must be rebuild. When the class instance of DataRow is filled in code and in Report class result is assigned via call e.g. DataSource = ReportCreator.Create(), then the data will be dynamically transfered into report. This is mostly via some report events, which are accessible via bolt icon in Properties tab.

Some reports has data binding via designed query, some XSD files. Mostly these will be replaced with dynamic data via ReportCreator class as ORM usage inside it.

Some reports are sets as master detail e.g. ReportUserRights. These reports are bound to the class, which is master record and has some detail records. Such report has to have Detail Bond component and DetailReport and some Details, which are inserted into detail report via click right to DetailReport and select “Insert Detail Report” → detail class name.

• DevExpress report designer tutorial
• DevExpress banded report for e.g. master detail documentation

• Copy configuration part of customer-dev/Service/PSAS.LiveDataProcessor.Service.exe.config into LiveServiceProcessorService/App.Config/
• In ServiceThreadTable search for thread name - column Name.
• Set the breakpoint into some LiveDataProcess.ServiceNameThread class, somewhere into %do_tick% method.
• Run LiveServiceProcessor application.
• In dialog, try to find thread by name a run it.
• Wait for breakpoint when is reached.

Integration (or ServiceTest) are grouped together in projects in PSAS_ServiceTest solution e.g ServiceTest/LiveDataProcessorPHM.Tests. Test runner can run tests parallel from different groups/projects. It means that only one test from one particular project can run once. It's used because each testing project has own database for tests, so only one test can use these database in particular time, it prevents the race conditions, locking database etc.

These are run on tfs server build server 4. Run test manually

• make build on Azure dev
• deploy on particular testing environment
• run tests manually with command

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" "c:\agent_interactive\_work\r1\a\PD1 Build Autodeployable\PD1 UI Tests\Debug\net47\GlobalTests.dll" /TestCaseFilter:"TestCategory=APL_LB&TestCategory=OpensProperlyModules&TestCategory!=Reports" /logger:"trx" /TestAdapterPath:"c:\agent_interactive\_work\r1\a\PD1 Build Autodeployable\PD1 UI Tests\"

Important part for run only particular tests.

/TestCaseFilter:"TestCategory=APL_LB&TestCategory=OpensProperlyModules&TestCategory!=Reports"

These are test for LogBook which opens page properly. But there can be problem with deployed master - it triggers the test automatically.

Jo a co jsi tam psal s tím že jsem na Tahiti a vyplňování stazky. To jsem opravdu kokot, protože vyplňuju svoz nějaké popelnici co je v Praze z počítače na Tahati, takže je jasné že bude problém.

Browsery vždycky zobrazují lokální čas podle nastavení celého počítače a jakmile by se do tohohle nativního chování začalo hrabat, tak je zaděláno na obrovské problémy naprosto všude kde pracuje v browseru s datumem a to bychom si tedy už fakt zavařili. Prostě si změním timezone v počítači na Prahu.

To už tedy posílat tu timezone klienta a ať si ty timeshifty dělá server při odesílání a ukládání dat a klienti pak uvidí to, co se děje někde v timezone dané někde nějakým nastavením na backendu pro zákazníka. Ale určitě neřešit na klientovi.

Ono do důsledku se klidně může lišit timezone jednotlivých lokalit jednoho zákazníka, nebo dokonce jednotlivých fyzických objektů - míst svozů, nádob, tras atd atd., např. v tom Maďarsku, Polsku atd atd. Takže každý “fyzický objekt” by měl mít i někde v db nastavenu timezone ale řešit by to měl server na základě timezone, co dostane od klienta.