How to Understand Existing System - system

I have to work on a existing ERP which has more then 3000 tables and 400+ ASP pages and 56+ ASPX pages .
This ERP is working perfect and i have to do some customization as per management requirement.
Now i am facing issue to start the study of the system.
Would like to know from where to start whether from DB/UI or how to map the database table
with UI OR what should be the way to study this type of big application.

Related

Building datawarehouse with multiple data sources and using SQL change tracking

I would like to setup a datawarehouse which can be used by our companies Qlik application. The applications where I would like to retrieve data from a mostly running on-premises and all have a SQL server database as a source. Application which doesn't have an accessible SQL server as a source can be accessed via a REST API and/or Webservice.
This is how the setup looks like:
Data warehouse is a SQL-server (Standard, no Express version)
SQL datasources are running on 3 different SQL-servers (2 are Standard, 1 is Express)
Other sources are Webservice and/or REST API accessibel (SaaS application).
The SQL-servers are all on-premises are located within our network. The SaaS application is running in a data center (cloud).
Preferable I would like to have data as live as possible and the load on the server as small as possible. To do so I was wondering if there are ETL-tools which work with SQL Change Tracking to keep track of changes on table level (so that changes are PUSH based on not PULL). If this is the case I can let them sync sequential and set per table if it has to be synced based on Change Tracking or only full sync a day. As soon as I have the data in my datawarehouse I can create some data transformations in the ETL-tool or with T-SQL, that doesn't matter.
Hopefully there are some people around here who can tell me which ETL tool to use. There is a lot of information on the internet, but not much who go into the subject of SQL Change Tracking.
Many thanks in advance!

Drupal module development, custom database tables, pages for managing those data

I'm completely new to Drupal development
I want to learn how to create basic module with such functionality:
Create module with custom database tables
Create one or several new pages as logical section of the site
Manage data from database tables on those newly created pages
For example, I want to create subscription service with clients database
and manage their data (edit clients, export, change their status, etc...)
I want to do this on new pages on my site (not in admin section)
site.com/clients - list of client
site.com/client - client detailed info
etc
Please, provide some thoughts or tutorials (but not a ready module :) )
You can follow this tutorial for the basics in creating a D7 module.
https://www.drupal.org/node/1074360
As far as custom database tables I suggest taking a look at this module.
https://www.drupal.org/project/eck
Also take a look at this video for more info about 'ECK'.
http://codekarate.com/daily-dose-of-drupal/drupal-7-entity-construction-kit

How to test SQL scripts? (Data Integrity/Migration Testing)

Our team (QA) is facing the following problem:
We have a database that is accessed only by our Core application which is a WCF services app. Our client applications are using the Core to access the database.
At some point we were provided with a new Version of our Core application and of our Database. The Dev department also gave us a sql script which is altering a big part of our database Core data. The core data are used by the Core Application to describe the Logic of our system, so every change on that data may have affects on any of our client application's functionality.
My questions are:
Should we test all of our applications again (even if they are
already fully tested) or is there is a more efficient way to test the
SQL script?
Is there a testing technique/tool for data integrity/migration testing?
I am looking for a quick validity/integrity testing of the database after running a migration script. That will prevent us losing time by testing it through the applications. If the validity/integrity testing is successful then we can test the apps.
There are unit testing frameworks available for T-SQL. The TSQLUnit project is one such framework. You can use it to set up automated testing, just like you would in the applications.
as #Tim Lentine already posted, I would recomend testing the full application. As you commented, the new sql script your team received has made important changes on the core of your database development, according to your description, both on the structure and the data itself. So in order to be sure that everything is still on one piece I would preferably do a full application test. As for a tool or technique I can recomend the new RedGate (no, I do not work for them) addon on the SSMS called "SQL Test". It uses the unit testing open source tSQLt for its purposes. It only has the drawback that someone will need to first learn how to work with tSQLt but is prettu straightforward.
From the description you gave:
We have a database that is accessed only by our Core application ...
we were provided with a new Version of our Core application and of
our Database ...
tells me it is not your team's responsibility to test the database in isolation, but you can test the Core service from your client's perspective and therefore assume the database is correct.
Treat the Core application and the database as a black box and test using Unit Tests. These test should not require you to go poking around in the database as for all intents and purposes any application using your Core application doesn't know, nor should care, that the information is actually stored in to a database. You development team could decide in 6 months they are going to store the data in the Cloud in which case all your database test will be broken.
If you do have to look in the database to check data has been stored correctly then there is a problem with your Core service's interface as any data you put in should be retrievable via the same interface (I just know someone is going to comment that their app does store data which cannot be read back but without a more detailed description of your app it's easier to generalise).
Back in the real world I am assuming you are part of the QA team and unless the database developers are doing some testing (they are, aren't they?) you are more than likely going to have to validate the database changes.
To the end you may be interested to read a question I posted on the DBA Stack Exchage site about performing a data comparison between two different schemas. Spoiler: there's no easy answer.
show below links :
http://www.simple-talk.com/sql/t-sql-programming/sql-server-unit-testing-with-tsqlt/
http://www.red-gate.com/products/sql-development/sql-test/

New to sharepoint development, do lists replace your database?

We're just starting Sharepoint development, and one of my first tasks is to build a data collection tool. It will be used across multiple sites, so there will be an admin area, and each site will pull in it's related questions, and record the data. I've gone through a bunch of tutorials on development, and have a fairly good idea of how to start. I just want to make sure I understand one thing. Do lists basically take the place of your database? If this was a regular app, I would create a question table, a link table that tells which questions are connected to which site, a table that stores the answer, linking to the site and question table.
Is this the basic pattern you follow, or should I be doing things differently for Sharepoint applications?
If the thought is to use an external databse, can anyone point me to some info on this?
In our Sharepoint project we stared with Lists. It was good to some point - till DB had only few relations between data. After adding tables and relations performance falls a lot and we had to switch to use standard DB in MS SQL Server. So I recomend to use DB.
Disadventages: you cannot use sharepoint controls to edit/view data and cannot restrict access to data from sharepoint level
Adventages: much faster access to data

Create ASP.net 3.5 web form application derived from Excel Workbook

Good Afternoon,
A customer has provided me with a spreadsheet file his team uses to provide quotes for a product. The spreadsheet has extensive data in underlying sheets and calls those sheets as part of the numerous formulas on the quote sheet.
I've been tasked with web-enabling this tool such that the quotes can be generated on the client's website, hosted in a shared environment, running ASP.net 3.5 webforms. The quote web form will be in a Restricted portion of the website controlled by ASP.net membership API.
Are there 3rd party tools that do well with this sort of thing?
Thanks,
Sid
I've once been asked to do something similar. I refused. Someone else tried this and it became a complete failure. That's because your design is based upon the structure of a spreadsheet.
When I was called back to help on this project, I kicked the previous code into a large bin, which will stay closed until Hell freezes over! I then started analysing the Excel sheets, extracting the business logic and writing them down as documentation. This allowed me to create a good design to set up the first version of a new project, which wasn't based upon the Excel sheet, just on the business logic in the sheet.
Don't be tempted to fall into this trap! It sounds too easy but in reality, it's way too expensive as a solution because of all the problems that you will encounter!If your customer really needs to have something to use real fast, start with .NET (VS2008 with latest service packs or better) and SQL Server. First create a simple database structure to contain the quotes. Add as many relations as needed. Then, using VS2008, create a new project based on the "Dynamic Data Entities Web Application" which will use the Entity Framework to connect to the database. Make sure the entity framework is connected to your database and all data is provided to it. (By adding an "ADO.NET Entity Data Model" to it.) Compile it, put it on the web server and version 0.1 should be ready. It will allow your customer to continue data entry, although in a bit primitive way, while maintaining the data integrity of it all. It still isn't good enough to expose to the outside World but it makes it easier to get rid of the data part of the Excel spreadsheet. (And technically, it should be possible to also add a RESTful service around the entity model within an hour to allow Excel to read data from a web service instead.)
When this start page has been created, your customer can get used to data entry through web pages while you have some time to analyse their spreadsheet a bit more to optimize the data model and to create custom logic and better pages for data entry.
Basically, this is the approach that I used. My customer had data in Excel sheets which was exported to an Access database which was used as read-only data for users of his application. He used Excel to keep the data up-to-date. But when multiple users started to maintain the data in the same Excel sheet, he got in big trouble, losing the integrity and data of the Excel sheets multiple times.
I first created a simple data model around the Excel data with the Entity framework/DDS for easier data entry and then I could optimize the database structure while the customer just continued to modify the data. Occasionally, I'd update the database structure, adding more relations and restructuring the data to be more optimized and at one point I added the RESTful service functionality so the customer could get the data as XML through a simple web request. Now the customer has completely forgotten about the Excel sheet and is using the website full-time. He has accepted the fact that turning it into some fancy website will cost a lot of time but the current situation is quite acceptable.
This approach succeeded where previous attempts failed simply because I only focused on the data, nothing more. Now I can improve it all using little steps. But step one: analyze the Excel sheet and dump the data in a database. The Entity framework will allow you to quickly build simple sites around this without much effort.