Showing posts with label master. Show all posts
Showing posts with label master. Show all posts

Wednesday, March 21, 2012

is it possible to create a Master Details Report?

is it possible to create a sort iof Master Details Report?

mean one dataset returning the master data while the other dataiset returns the details

and then relate this two datasets on a common key and show the report .

You can use drillthrough or subreports to do this. The dataset in the main report would return the master data, which is displayed in the main report. In the drillthrough link or subreport, you can then pass the key through parameters.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rscreate/htm/rcr_creating_interactive_v1_38tn.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rscreate/htm/rcr_creating_layout_v1_2584.asp

|||

hi thanks for your reply, i understand that we can do this using drill down reports, what i want to know is is it possible that in a same report i.e. RDL file can i have master and detail datasets and relate this two and report them in a table.

Example:

MasterDataset has following records

EmpNo. FirstName Last Name.

1 john Smith

2 Tom Knight

DetailsDataSet

EmpNo. DepNo DeptName

1 1 prodcution

1 2 Accounts

2 1 production

2 2 Accounts

I want this two datsets to be related on empno and then display them on the table, such that each employees is shown on a new page, with its department details.

Thanks.

|||

You would really be better off creating a subreport with the details. Then link the master report to the subreport based on a paramater. Then you can put a pagebreak at the end of the first report, thereby putting the details on the next page.

So, you'll have two .rdl files but the user will only see one report.

Monday, March 12, 2012

Is it ok to run DBCC Checkdb on msdb and master?

Will I encounter any issues running DBCC CHECKDB on either msdb or master?

Thanks!

I just wouldn't recommend using any of the [REPAIR_...] options.

It is a good idea to do so before a backup to have confidence that the backup is ok. (About the backup if there is a problem - and alert the DBA.

Wednesday, March 7, 2012

Is is a good practice to use autoincrement in access

Hi just new here in the forum i have a question

is it a good practice to use autoincrement fields in an access database for master and detail? and for unique record identification. if not please tell why..
im currently using access and with autoincrement for unique record identification and for master and detail.. then there is a possibilities to transfer from access to mssql. will i encounter problems when migrating since i am using an autoincrement fields

in mssql is there an autoincrement fields like access?

dont be harsh ok.. just anoob trying to learn. :eek:The equivalent of autoincrement in SQL server is the IDENTITY property.
It is possible to port existing ID values into a SQL Server table with an identity property set, but to do so you will need to temporarily turn off the identity property, and then reset it when the data load is complete.
The upsizing wizard for Access -> SQL Server may handle this for you.|||The equivalent of autoincrement in SQL server is the IDENTITY property.
It is possible to port existing ID values into a SQL Server table with an identity property set, but to do so you will need to temporarily turn off the identity property, and then reset it when the data load is complete.
The upsizing wizard for Access -> SQL Server may handle this for you.

thanks for the fast reply blindman.. but, is it a good practice to use autoincrement in a master detail ?? my master table will have an autoincrement fields, my detail will have a longint field to accomodate for the master's autoincrement field.
i will be using this method on a library program ..|||What is going to be the primary key of the detail table? A natural composite key including the master ID, or are you going to create a new surrogate key (possibly autoincremented)?|||What is going to be the primary key of the detail table? A natural composite key including the master ID, or are you going to create a new surrogate key (possibly autoincremented)?

the primary key of the detail table will be another autoincrement fields but with no relation whatsoever on the master field.|||An surrogate key on a detail table is not required, though it may facilitate SQL coding and programming the interface. You can leave it off and still have functional database design using the natural key of the detail table. Note that the natural key of the detail table is usually a composite of the surrogate key of the master table and some detail element that is unique within each master record.
One other thing; you keep asking whether it is good practice to use an autoincrementing column for a key. In SQL Server you basically have two choices for surrogate keys, and those are auto-incrementing identity values and GUIDs (Globally Unique Identifiers). Stick to using either of these. By definition surrogate keys should bear no relation to the underlying data, so you shouldn't be spending time mucking arround with methods of generating them. Hence, auto-generated surrogate keys such as Idenity columns and GUIDs are preferred.|||An surrogate key on a detail table is not required, though it may facilitate SQL coding and programming the interface. You can leave it off and still have functional database design using the natural key of the detail table. Note that the natural key of the detail table is usually a composite of the surrogate key of the master table and some detail element that is unique within each master record.
One other thing; you keep asking whether it is good practice to use an autoincrementing column for a key. In SQL Server you basically have two choices for surrogate keys, and those are auto-incrementing identity values and GUIDs (Globally Unique Identifiers). Stick to using either of these. By definition surrogate keys should bear no relation to the underlying data, so you shouldn't be spending time mucking arround with methods of generating them. Hence, auto-generated surrogate keys such as Idenity columns and GUIDs are preferred.

thanks.. i thought that i am at a lost.. thanks for clarifying those things. at least now i can sleep well coz i wont change the autoincrement fields into my own generated nos.. thanks again blindman. your a great help..