Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Reporting

23 posts in Commercial ISV's Last posting was on 2008-04-02 11:01:08.0Z
M. Searer Posted on 2008-02-20 22:42:33.0Z
From: "M. Searer" <nospam@nospam.com>
Newsgroups: sybase.public.commercial-isv.general
Subject: Reporting
Lines: 14
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <47bcacd9$1@forums-1-dub>
Date: 20 Feb 2008 14:42:33 -0800
X-Trace: forums-1-dub 1203547353 10.22.241.152 (20 Feb 2008 14:42:33 -0800)
X-Original-Trace: 20 Feb 2008 14:42:33 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:71
Article PK: 103792

I know a lot of people use crystal for either their standard reporting and/or
custom client reports rather than use PB/Infomaker.

For custom reporting (reports that customers do themselves) we push Infomaker.
In fact, we have load existing reports for them automatically into infomaker
from within the PB application. We don't have a means (yet) to get the report
back into our application as cleanly as I would like, but the basics are there.
The other reason I like infomaker over crystal for the custom reporting is that
we provide the means for the users to setup drill back from any infomaker based
report to have it open the windows that the information came from.

For those of you using Crystal (or other reporting tools), my question is why?


Yoyo Young Posted on 2008-02-21 00:38:24.0Z
Reply-To: "Yoyo Young" <young@public1.wx.js.cn>
From: "Yoyo Young" <young@public1.wx.js.cn>
Newsgroups: sybase.public.commercial-isv.general
References: <47bcacd9$1@forums-1-dub>
Subject: Re: Reporting
Lines: 35
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.3790.3959
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <47bcc800$1@forums-1-dub>
Date: 20 Feb 2008 16:38:24 -0800
X-Trace: forums-1-dub 1203554304 10.22.241.152 (20 Feb 2008 16:38:24 -0800)
X-Original-Trace: 20 Feb 2008 16:38:24 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:72
Article PK: 103791

Before discussion, we'd better ask a few questions. What's the report? How
many types of report? Different type has different solution.
In my definition, there are three types of report. One is 'static' or 'hard'
report, for example, Purchase Order report, Sales order report. Most of the
type is free form style and has a exciting layout. And the best tool for it
is datawindow designer. Second is query report. Most of the type is grid
style. You would input search parameters and get result. In addition, you
can define search parameters and query select sql. I developed a query tool
based on the Brad's querybuilder for this type of report. The last one is
OLAP or pivot table. I developed a BI tool with Contourcube component(the
best BI component for SMB), which can intergrate with PB. You can download
it from http://www.youngsoft.com.cn/HnD for try.

Yoyo

"M. Searer" <nospam@nospam.com> wrote in message
news:47bcacd9$1@forums-1-dub...
>I know a lot of people use crystal for either their standard reporting
>and/or custom client reports rather than use PB/Infomaker.
>
> For custom reporting (reports that customers do themselves) we push
> Infomaker. In fact, we have load existing reports for them automatically
> into infomaker from within the PB application. We don't have a means
> (yet) to get the report back into our application as cleanly as I would
> like, but the basics are there. The other reason I like infomaker over
> crystal for the custom reporting is that we provide the means for the
> users to setup drill back from any infomaker based report to have it open
> the windows that the information came from.
>
> For those of you using Crystal (or other reporting tools), my question is
> why?
>


M. Searer Posted on 2008-02-22 17:17:02.0Z
From: "M. Searer" <nospam@nospam.com>
Newsgroups: sybase.public.commercial-isv.general
References: <47bcacd9$1@forums-1-dub> <47bcc800$1@forums-1-dub>
Subject: Re: Reporting
Lines: 57
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <47bf038e$1@forums-1-dub>
Date: 22 Feb 2008 09:17:02 -0800
X-Trace: forums-1-dub 1203700622 10.22.241.152 (22 Feb 2008 09:17:02 -0800)
X-Original-Trace: 22 Feb 2008 09:17:02 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:74
Article PK: 103796

I like your breakouts for reporting types.

I consider our 'static' reports to be of two types: stored procedure based
(which we try to stay away from), and sql based (non stored procedure).
The reason we make the differentiation is that we allow our static non-stored
procedure reports to have their parameters added/changed at run time - the user
can either change the operator of an parameter ('=' changed to '<>' for example)
and/or add another parameter. So we do provide some minor 'query report' type
capabilities in our static non-stored procedure reports. This added flexibility
is why we try to stay away from stored procedure reports. It is also another
reason I prefer PB/Infomaker reports.

For your query reports, do you utilize a data dictionary to make it easier for
your end users to do the reports?

I will look at the contourcube info, thanks.

"Yoyo Young" <young@public1.wx.js.cn> wrote in message
news:47bcc800$1@forums-1-dub...
> Before discussion, we'd better ask a few questions. What's the report? How
> many types of report? Different type has different solution.
> In my definition, there are three types of report. One is 'static' or 'hard'
> report, for example, Purchase Order report, Sales order report. Most of the
> type is free form style and has a exciting layout. And the best tool for it
> is datawindow designer. Second is query report. Most of the type is grid
> style. You would input search parameters and get result. In addition, you can
> define search parameters and query select sql. I developed a query tool based
> on the Brad's querybuilder for this type of report. The last one is OLAP or
> pivot table. I developed a BI tool with Contourcube component(the best BI
> component for SMB), which can intergrate with PB. You can download it from
> http://www.youngsoft.com.cn/HnD for try.
>
> Yoyo
>
>
> "M. Searer" <nospam@nospam.com> wrote in message
> news:47bcacd9$1@forums-1-dub...
>>I know a lot of people use crystal for either their standard reporting and/or
>>custom client reports rather than use PB/Infomaker.
>>
>> For custom reporting (reports that customers do themselves) we push
>> Infomaker. In fact, we have load existing reports for them automatically into
>> infomaker from within the PB application. We don't have a means (yet) to
>> get the report back into our application as cleanly as I would like, but the
>> basics are there. The other reason I like infomaker over crystal for the
>> custom reporting is that we provide the means for the users to setup drill
>> back from any infomaker based report to have it open the windows that the
>> information came from.
>>
>> For those of you using Crystal (or other reporting tools), my question is
>> why?
>>
>
>


Yoyo Young Posted on 2008-02-25 14:10:14.0Z
Reply-To: "Yoyo Young" <young@public1.wx.js.cn>
From: "Yoyo Young" <young@public1.wx.js.cn>
Newsgroups: sybase.public.commercial-isv.general
References: <47bcacd9$1@forums-1-dub> <47bcc800$1@forums-1-dub> <47bf038e$1@forums-1-dub>
Subject: Re: Reporting
Lines: 70
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.3790.3959
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <47c2cc46@forums-1-dub>
Date: 25 Feb 2008 06:10:14 -0800
X-Trace: forums-1-dub 1203948614 10.22.241.152 (25 Feb 2008 06:10:14 -0800)
X-Original-Trace: 25 Feb 2008 06:10:14 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:75
Article PK: 103797

As for data dictionary, I always was confused by it. Many developers define
it as simple as maintain tables and columns description. And the
relationship between entities(tables) is hard for end users to understand.
What's your good practice?

Yoyo

"M. Searer" <nospam@nospam.com> wrote in message
news:47bf038e$1@forums-1-dub...
>I like your breakouts for reporting types.
>
> I consider our 'static' reports to be of two types: stored procedure based
> (which we try to stay away from), and sql based (non stored procedure).
> The reason we make the differentiation is that we allow our static
> non-stored procedure reports to have their parameters added/changed at run
> time - the user can either change the operator of an parameter ('='
> changed to '<>' for example) and/or add another parameter. So we do
> provide some minor 'query report' type capabilities in our static
> non-stored procedure reports. This added flexibility is why we try to
> stay away from stored procedure reports. It is also another reason I
> prefer PB/Infomaker reports.
>
> For your query reports, do you utilize a data dictionary to make it easier
> for your end users to do the reports?
>
> I will look at the contourcube info, thanks.
>
>
> "Yoyo Young" <young@public1.wx.js.cn> wrote in message
> news:47bcc800$1@forums-1-dub...
>> Before discussion, we'd better ask a few questions. What's the report?
>> How many types of report? Different type has different solution.
>> In my definition, there are three types of report. One is 'static' or
>> 'hard' report, for example, Purchase Order report, Sales order report.
>> Most of the type is free form style and has a exciting layout. And the
>> best tool for it is datawindow designer. Second is query report. Most of
>> the type is grid style. You would input search parameters and get result.
>> In addition, you can define search parameters and query select sql. I
>> developed a query tool based on the Brad's querybuilder for this type of
>> report. The last one is OLAP or pivot table. I developed a BI tool with
>> Contourcube component(the best BI component for SMB), which can
>> intergrate with PB. You can download it from
>> http://www.youngsoft.com.cn/HnD for try.
>>
>> Yoyo
>>
>>
>> "M. Searer" <nospam@nospam.com> wrote in message
>> news:47bcacd9$1@forums-1-dub...
>>>I know a lot of people use crystal for either their standard reporting
>>>and/or custom client reports rather than use PB/Infomaker.
>>>
>>> For custom reporting (reports that customers do themselves) we push
>>> Infomaker. In fact, we have load existing reports for them automatically
>>> into infomaker from within the PB application. We don't have a means
>>> (yet) to get the report back into our application as cleanly as I would
>>> like, but the basics are there. The other reason I like infomaker over
>>> crystal for the custom reporting is that we provide the means for the
>>> users to setup drill back from any infomaker based report to have it
>>> open the windows that the information came from.
>>>
>>> For those of you using Crystal (or other reporting tools), my question
>>> is why?
>>>
>>
>>
>
>


M. Searer Posted on 2008-02-27 15:42:53.0Z
From: "M. Searer" <nospam@nospam.com>
Newsgroups: sybase.public.commercial-isv.general
References: <47bcacd9$1@forums-1-dub> <47bcc800$1@forums-1-dub> <47bf038e$1@forums-1-dub> <47c2cc46@forums-1-dub>
Subject: Re: Reporting
Lines: 89
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <47c584fd$1@forums-1-dub>
Date: 27 Feb 2008 07:42:53 -0800
X-Trace: forums-1-dub 1204126973 10.22.241.152 (27 Feb 2008 07:42:53 -0800)
X-Original-Trace: 27 Feb 2008 07:42:53 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:80
Article PK: 103801

Yes, in this context a data-dictionary provides descriptions of the columns and
tables that a reporting user can understand. So defining something as a
foreign key to table Y wouldn't be good enough. As for my question, I was
really wondering if you provide a table based data-dictionary that your
query/reporting tool links to so that the users get a list of tables names with
descriptions, and column names with descriptions. The powerbuilder pbcat (?)
tables provide the capability to store comments for the tables/columns and so
provides this capability in infomaker/pb. I think the presentation of this
information to a non-tech user could be greatly improved within infomaker, but
at least it is pre-built and could be reused between a query tool like you have
built, and infomaker.

I agree that often end-users won't understand the relationships between tables.
However, even a very simple (single table) integrated reporting tool is a nice
feature. Limiting it to a single table may even be best as it prevents users
from accidentally doing Cartesian products in a production database.

"Yoyo Young" <young@public1.wx.js.cn> wrote in message
news:47c2cc46@forums-1-dub...
> As for data dictionary, I always was confused by it. Many developers define it
> as simple as maintain tables and columns description. And the relationship
> between entities(tables) is hard for end users to understand. What's your good
> practice?
>
> Yoyo
>
> "M. Searer" <nospam@nospam.com> wrote in message
> news:47bf038e$1@forums-1-dub...
>>I like your breakouts for reporting types.
>>
>> I consider our 'static' reports to be of two types: stored procedure based
>> (which we try to stay away from), and sql based (non stored procedure).
>> The reason we make the differentiation is that we allow our static non-stored
>> procedure reports to have their parameters added/changed at run time - the
>> user can either change the operator of an parameter ('=' changed to '<>' for
>> example) and/or add another parameter. So we do provide some minor 'query
>> report' type capabilities in our static non-stored procedure reports. This
>> added flexibility is why we try to stay away from stored procedure reports.
>> It is also another reason I prefer PB/Infomaker reports.
>>
>> For your query reports, do you utilize a data dictionary to make it easier
>> for your end users to do the reports?
>>
>> I will look at the contourcube info, thanks.
>>
>>
>> "Yoyo Young" <young@public1.wx.js.cn> wrote in message
>> news:47bcc800$1@forums-1-dub...
>>> Before discussion, we'd better ask a few questions. What's the report? How
>>> many types of report? Different type has different solution.
>>> In my definition, there are three types of report. One is 'static' or 'hard'
>>> report, for example, Purchase Order report, Sales order report. Most of the
>>> type is free form style and has a exciting layout. And the best tool for it
>>> is datawindow designer. Second is query report. Most of the type is grid
>>> style. You would input search parameters and get result. In addition, you
>>> can define search parameters and query select sql. I developed a query tool
>>> based on the Brad's querybuilder for this type of report. The last one is
>>> OLAP or pivot table. I developed a BI tool with Contourcube component(the
>>> best BI component for SMB), which can intergrate with PB. You can download
>>> it from http://www.youngsoft.com.cn/HnD for try.
>>>
>>> Yoyo
>>>
>>>
>>> "M. Searer" <nospam@nospam.com> wrote in message
>>> news:47bcacd9$1@forums-1-dub...
>>>>I know a lot of people use crystal for either their standard reporting
>>>>and/or custom client reports rather than use PB/Infomaker.
>>>>
>>>> For custom reporting (reports that customers do themselves) we push
>>>> Infomaker. In fact, we have load existing reports for them automatically
>>>> into infomaker from within the PB application. We don't have a means
>>>> (yet) to get the report back into our application as cleanly as I would
>>>> like, but the basics are there. The other reason I like infomaker over
>>>> crystal for the custom reporting is that we provide the means for the users
>>>> to setup drill back from any infomaker based report to have it open the
>>>> windows that the information came from.
>>>>
>>>> For those of you using Crystal (or other reporting tools), my question is
>>>> why?
>>>>
>>>
>>>
>>
>>
>
>


Yoyo Young Posted on 2008-02-28 12:37:47.0Z
Reply-To: "Yoyo Young" <young@public1.wx.js.cn>
From: "Yoyo Young" <young@public1.wx.js.cn>
Newsgroups: sybase.public.commercial-isv.general
References: <47bcacd9$1@forums-1-dub> <47bcc800$1@forums-1-dub> <47bf038e$1@forums-1-dub> <47c2cc46@forums-1-dub> <47c584fd$1@forums-1-dub>
Subject: Re: Reporting
Lines: 106
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.3790.3959
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <47c6ab1b@forums-1-dub>
Date: 28 Feb 2008 04:37:47 -0800
X-Trace: forums-1-dub 1204202267 10.22.241.152 (28 Feb 2008 04:37:47 -0800)
X-Original-Trace: 28 Feb 2008 04:37:47 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:81
Article PK: 103802

The powerbuilder pbcat (?) tables are good. However it can't deal with multi
language description. I will give it a try.

Thanks.

Yoyo

"M. Searer" <nospam@nospam.com> wrote in message
news:47c584fd$1@forums-1-dub...
> Yes, in this context a data-dictionary provides descriptions of the
> columns and tables that a reporting user can understand. So defining
> something as a foreign key to table Y wouldn't be good enough. As for my
> question, I was really wondering if you provide a table based
> data-dictionary that your query/reporting tool links to so that the users
> get a list of tables names with descriptions, and column names with
> descriptions. The powerbuilder pbcat (?) tables provide the capability to
> store comments for the tables/columns and so provides this capability in
> infomaker/pb. I think the presentation of this information to a non-tech
> user could be greatly improved within infomaker, but at least it is
> pre-built and could be reused between a query tool like you have built,
> and infomaker.
>
> I agree that often end-users won't understand the relationships between
> tables. However, even a very simple (single table) integrated reporting
> tool is a nice feature. Limiting it to a single table may even be best as
> it prevents users from accidentally doing Cartesian products in a
> production database.
>
> "Yoyo Young" <young@public1.wx.js.cn> wrote in message
> news:47c2cc46@forums-1-dub...
>> As for data dictionary, I always was confused by it. Many developers
>> define it as simple as maintain tables and columns description. And the
>> relationship between entities(tables) is hard for end users to
>> understand. What's your good practice?
>>
>> Yoyo
>>
>> "M. Searer" <nospam@nospam.com> wrote in message
>> news:47bf038e$1@forums-1-dub...
>>>I like your breakouts for reporting types.
>>>
>>> I consider our 'static' reports to be of two types: stored procedure
>>> based (which we try to stay away from), and sql based (non stored
>>> procedure).
>>> The reason we make the differentiation is that we allow our static
>>> non-stored procedure reports to have their parameters added/changed at
>>> run time - the user can either change the operator of an parameter ('='
>>> changed to '<>' for example) and/or add another parameter. So we do
>>> provide some minor 'query report' type capabilities in our static
>>> non-stored procedure reports. This added flexibility is why we try to
>>> stay away from stored procedure reports. It is also another reason I
>>> prefer PB/Infomaker reports.
>>>
>>> For your query reports, do you utilize a data dictionary to make it
>>> easier for your end users to do the reports?
>>>
>>> I will look at the contourcube info, thanks.
>>>
>>>
>>> "Yoyo Young" <young@public1.wx.js.cn> wrote in message
>>> news:47bcc800$1@forums-1-dub...
>>>> Before discussion, we'd better ask a few questions. What's the report?
>>>> How many types of report? Different type has different solution.
>>>> In my definition, there are three types of report. One is 'static' or
>>>> 'hard' report, for example, Purchase Order report, Sales order report.
>>>> Most of the type is free form style and has a exciting layout. And the
>>>> best tool for it is datawindow designer. Second is query report. Most
>>>> of the type is grid style. You would input search parameters and get
>>>> result. In addition, you can define search parameters and query select
>>>> sql. I developed a query tool based on the Brad's querybuilder for this
>>>> type of report. The last one is OLAP or pivot table. I developed a BI
>>>> tool with Contourcube component(the best BI component for SMB), which
>>>> can intergrate with PB. You can download it from
>>>> http://www.youngsoft.com.cn/HnD for try.
>>>>
>>>> Yoyo
>>>>
>>>>
>>>> "M. Searer" <nospam@nospam.com> wrote in message
>>>> news:47bcacd9$1@forums-1-dub...
>>>>>I know a lot of people use crystal for either their standard reporting
>>>>>and/or custom client reports rather than use PB/Infomaker.
>>>>>
>>>>> For custom reporting (reports that customers do themselves) we push
>>>>> Infomaker. In fact, we have load existing reports for them
>>>>> automatically into infomaker from within the PB application. We
>>>>> don't have a means (yet) to get the report back into our application
>>>>> as cleanly as I would like, but the basics are there. The other reason
>>>>> I like infomaker over crystal for the custom reporting is that we
>>>>> provide the means for the users to setup drill back from any infomaker
>>>>> based report to have it open the windows that the information came
>>>>> from.
>>>>>
>>>>> For those of you using Crystal (or other reporting tools), my question
>>>>> is why?
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


M. Searer Posted on 2008-02-28 16:49:45.0Z
From: "M. Searer" <nospam@nospam.com>
Newsgroups: sybase.public.commercial-isv.general
References: <47bcacd9$1@forums-1-dub> <47bcc800$1@forums-1-dub> <47bf038e$1@forums-1-dub> <47c2cc46@forums-1-dub> <47c584fd$1@forums-1-dub> <47c6ab1b@forums-1-dub>
Subject: Re: Reporting
Lines: 111
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <47c6e629@forums-1-dub>
Date: 28 Feb 2008 08:49:45 -0800
X-Trace: forums-1-dub 1204217385 10.22.241.152 (28 Feb 2008 08:49:45 -0800)
X-Original-Trace: 28 Feb 2008 08:49:45 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:82
Article PK: 103804

good point on the language limitations. You should request that as an
enhancement for infomaker/pb. You might need to extend that request out to
powerdesigner as well since that is good repository for the definitions and can
generate them out to the pbcat tables.

"Yoyo Young" <young@public1.wx.js.cn> wrote in message
news:47c6ab1b@forums-1-dub...
> The powerbuilder pbcat (?) tables are good. However it can't deal with multi
> language description. I will give it a try.
>
> Thanks.
>
> Yoyo
>
> "M. Searer" <nospam@nospam.com> wrote in message
> news:47c584fd$1@forums-1-dub...
>> Yes, in this context a data-dictionary provides descriptions of the columns
>> and tables that a reporting user can understand. So defining something as a
>> foreign key to table Y wouldn't be good enough. As for my question, I was
>> really wondering if you provide a table based data-dictionary that your
>> query/reporting tool links to so that the users get a list of tables names
>> with descriptions, and column names with descriptions. The powerbuilder
>> pbcat (?) tables provide the capability to store comments for the
>> tables/columns and so provides this capability in infomaker/pb. I think the
>> presentation of this information to a non-tech user could be greatly improved
>> within infomaker, but at least it is pre-built and could be reused between a
>> query tool like you have built, and infomaker.
>>
>> I agree that often end-users won't understand the relationships between
>> tables. However, even a very simple (single table) integrated reporting tool
>> is a nice feature. Limiting it to a single table may even be best as it
>> prevents users from accidentally doing Cartesian products in a production
>> database.
>>
>> "Yoyo Young" <young@public1.wx.js.cn> wrote in message
>> news:47c2cc46@forums-1-dub...
>>> As for data dictionary, I always was confused by it. Many developers define
>>> it as simple as maintain tables and columns description. And the
>>> relationship between entities(tables) is hard for end users to understand.
>>> What's your good practice?
>>>
>>> Yoyo
>>>
>>> "M. Searer" <nospam@nospam.com> wrote in message
>>> news:47bf038e$1@forums-1-dub...
>>>>I like your breakouts for reporting types.
>>>>
>>>> I consider our 'static' reports to be of two types: stored procedure based
>>>> (which we try to stay away from), and sql based (non stored procedure).
>>>> The reason we make the differentiation is that we allow our static
>>>> non-stored procedure reports to have their parameters added/changed at run
>>>> time - the user can either change the operator of an parameter ('=' changed
>>>> to '<>' for example) and/or add another parameter. So we do provide some
>>>> minor 'query report' type capabilities in our static non-stored procedure
>>>> reports. This added flexibility is why we try to stay away from stored
>>>> procedure reports. It is also another reason I prefer PB/Infomaker reports.
>>>>
>>>> For your query reports, do you utilize a data dictionary to make it easier
>>>> for your end users to do the reports?
>>>>
>>>> I will look at the contourcube info, thanks.
>>>>
>>>>
>>>> "Yoyo Young" <young@public1.wx.js.cn> wrote in message
>>>> news:47bcc800$1@forums-1-dub...
>>>>> Before discussion, we'd better ask a few questions. What's the report? How
>>>>> many types of report? Different type has different solution.
>>>>> In my definition, there are three types of report. One is 'static' or
>>>>> 'hard' report, for example, Purchase Order report, Sales order report.
>>>>> Most of the type is free form style and has a exciting layout. And the
>>>>> best tool for it is datawindow designer. Second is query report. Most of
>>>>> the type is grid style. You would input search parameters and get result.
>>>>> In addition, you can define search parameters and query select sql. I
>>>>> developed a query tool based on the Brad's querybuilder for this type of
>>>>> report. The last one is OLAP or pivot table. I developed a BI tool with
>>>>> Contourcube component(the best BI component for SMB), which can intergrate
>>>>> with PB. You can download it from http://www.youngsoft.com.cn/HnD for try.
>>>>>
>>>>> Yoyo
>>>>>
>>>>>
>>>>> "M. Searer" <nospam@nospam.com> wrote in message
>>>>> news:47bcacd9$1@forums-1-dub...
>>>>>>I know a lot of people use crystal for either their standard reporting
>>>>>>and/or custom client reports rather than use PB/Infomaker.
>>>>>>
>>>>>> For custom reporting (reports that customers do themselves) we push
>>>>>> Infomaker. In fact, we have load existing reports for them automatically
>>>>>> into infomaker from within the PB application. We don't have a means
>>>>>> (yet) to get the report back into our application as cleanly as I would
>>>>>> like, but the basics are there. The other reason I like infomaker over
>>>>>> crystal for the custom reporting is that we provide the means for the
>>>>>> users to setup drill back from any infomaker based report to have it open
>>>>>> the windows that the information came from.
>>>>>>
>>>>>> For those of you using Crystal (or other reporting tools), my question is
>>>>>> why?
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


Hans Groeneveld Posted on 2008-02-22 10:47:21.0Z
From: "Hans Groeneveld" <h.groeneNOveld@tsdSPAM.nl>
Newsgroups: sybase.public.commercial-isv.general
References: <47bcacd9$1@forums-1-dub>
Subject: Re: Reporting
Lines: 39
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.3790.3959
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <47bea839$1@forums-1-dub>
Date: 22 Feb 2008 02:47:21 -0800
X-Trace: forums-1-dub 1203677241 10.22.241.152 (22 Feb 2008 02:47:21 -0800)
X-Original-Trace: 22 Feb 2008 02:47:21 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:73
Article PK: 103795

We use Crystal Reports because in the past datawindows did not have a
autoheight property for non-detail bands. Making it impossible to create
good looking reports. Therefor we needed a third party product for our
reports.

Maybe, with PB10.5 we would decide for PB instead of Crystal Reports. PB is
a lot of faster then Crystal Reports. CR does have his own bugsl. And for CR
XI you have to install a large application.

Advantage of CR is that it is a tool more commom then Infomaker. Some
customers do have experience with CR already. CR is tool specific for
creating reports and does that job well, you can create every report you
want.

Maybe you can search for a list that shows all the possibilities of CR and
look if you need it and if it is supported by PB also...

Kind Regard
Hans

"M. Searer" <nospam@nospam.com> wrote in message
news:47bcacd9$1@forums-1-dub...
>I know a lot of people use crystal for either their standard reporting
>and/or custom client reports rather than use PB/Infomaker.
>
> For custom reporting (reports that customers do themselves) we push
> Infomaker. In fact, we have load existing reports for them automatically
> into infomaker from within the PB application. We don't have a means
> (yet) to get the report back into our application as cleanly as I would
> like, but the basics are there. The other reason I like infomaker over
> crystal for the custom reporting is that we provide the means for the
> users to setup drill back from any infomaker based report to have it open
> the windows that the information came from.
>
> For those of you using Crystal (or other reporting tools), my question is
> why?
>


Derek Asirvadem Posted on 2008-03-26 11:45:37.0Z
From: Derek Asirvadem <derek@softwaregemsNOSPAMcomDOTau>
Organization: Software Gems Pty Ltd
Newsgroups: sybase.public.commercial-isv.general
Message-ID: <47ea3760@forums-1-dub>
References: <47bcacd9$1@forums-1-dub>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Reporting
User-Agent: Unison/1.7.7
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 26 Mar 2008 03:45:37 -0800
X-Trace: forums-1-dub 1206531937 10.22.241.152 (26 Mar 2008 03:45:37 -0800)
X-Original-Trace: 26 Mar 2008 03:45:37 -0800, vip152.sybase.com
Lines: 83
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:90
Article PK: 103809


> On 2008-02-21 09:42:33 +1100, "M. Searer" <nospam@nospam.com> said:
>
> I know a lot of people use crystal for either their standard reporting
> and/or custom client reports rather than use PB/Infomaker ... For
> those of you using Crystal (or other reporting tools), my question is
> why?

Here is our approach. Dozens of full implementations plus our own very
large Ivestment Mgmt app.

1 The days of the database being only accessible by, or heavily
dependent on, the app, are long gone. We follow Open Architecture
standards, in essence, that means the database is entirely independent
of the app. In our vertical (banks & finance), custs need that
reassurance, if not compliance. They own the data (database) forever,
but the apps that sit on top of it come and go.

2 That means true Relational DBMS, Twelve Rules (compliance grid due
to HP requirements), 4NF Normalisation, plus High Performance
structures. The users, but not the developers, get views.

3 All xacts are sprocs; no direct updates allowed, for performance,
integrity and security reasons. The xacts are logical business
functions like "add order" implemented to OLTP & ACID standards, never
"insert a row". These principles allow HP and scaleability, and have
no deadlocks. It is pedestrian to exec the one xact/sproc from both PB
(inhouse Client app) and EAServer (middleware hosting a web-facing app)
to perform the single business function and update the database. The
java caller needs an additional "wrapper" sproc for the xact/sproc.

4 Therefore we do not tell them what they should/must use for
reporting. Usually they already have a few licensed tools. Horses for
courses. Depending on whether the user is a simpleton, or the report
is complex, or they need drill-down, pivot, OLAP, etc. Anything will
do, from Excel to Crystal Reports to BusinessObjects (which we do NOT
push). CR is the most common request by a long shot. The point is,
there is no real "report building" after implementation. Users these
days are quite used to having many windows open at the same time, to
view data via different methods, and to update it via a single [PB]
app/window.

5 Due to the strict Normalisation, gathering info for "complex"
reports is not complex, and very few report sprocs are required.
Likewise tempdb is not overused, views do not have to be constructed
and built, the views are straight joins.

6 PB is used for the entire inhouse Client app. All drop-downs,
working grids (for whatever the user has to scan through to do their
work), etc are DataWindows. No reporting from PB except to print any
DataWindow with a bit of filtering and a bit of smarts, which uses a
(our own) PFC definition. That is one object for the app, not per
DataWindow.

7 Data Dictionary. For smaller Dbs, a syscomments entry for every
column is usually enough (which is available from the report tool;
pbcat etc is the wrong place). For larger Dbs, a full DD is demanded,
and that too in the tool of choice by the customer, because that is
where they are going to need it: for a big BO implementation, we have
built the Universe; for others we have built the DD likewise in the
reporting tool or PowerDesigner or ERwin (you won't believe how many
people still have it). Again the true normalisation makes this
exercise straight-forward and uncomplicated, and probably more
important, easy to change.

BTW, wearing my other hat as P&T expert, after scores of assignments, I
can categorically tell you that incorrect Normalisation or lack of
Normalisation (masquerading as "denormalised for performance") is the
single biggest error that app/Db designers make, and it affects every
area of the app/Db. Correct Normalisation makes a smaller, much faster
Db, certainly with more relationships (FKs), every time.

Incid. The big app is set up with a BO Universe, as that was demanded
by the first cust; we are replacing that with CR in the next version.
It does not require an Universe (great for overcoming the limitations
of an unnormalised filing system), and BO is prohibitively expensive.
They have acquired CR for the client list and to hit people like us.
--
Regards
Derek Asirvadem
Director / Senior Sybase DBA / Information Architect
Copyright © 2008 Software Gems Pty Ltd
Sybase BSA Partner


"jeff" Posted on 2008-03-26 12:56:36.0Z
Reply-To: "jeff" <jhersey at allnorth dottt com>
From: "jeff" <jhersey at allnorth dottt com>
Newsgroups: sybase.public.commercial-isv.general
References: <47bcacd9$1@forums-1-dub> <47ea3760@forums-1-dub>
Subject: Re: Reporting
Lines: 123
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <47ea4804$1@forums-1-dub>
Date: 26 Mar 2008 04:56:36 -0800
X-Trace: forums-1-dub 1206536196 10.22.241.152 (26 Mar 2008 04:56:36 -0800)
X-Original-Trace: 26 Mar 2008 04:56:36 -0800, vip152.sybase.com
X-Authenticated-User: pb110beta
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:91
Article PK: 103811

Derek,

on a side note regarding normalization ... The biggest hurdle with
normalization I've encountered is when there is time dependency of data.

Example...
Patient Demographics table stores POSTAL CODE
Encounters table stores visit to an institution / facility.
---------------
a patient's POSTAL CODE can change over time ... but it is important for
reporting that we know the postal code for each encounter. Just because a
patient moves, does that mean their history moves too -> spacial
representation of data / disease tracking?

So, in a normalize approach would you ...

1. Store Postal Code in Patient Table.
2. Store a 'log'of postal codes with and effective and expiry date.
3. when needed, get the postal code for each encounter from the postal code
log table.
or
1. would you just put the current postal code in to the encounter table?

This is similar to name, address, gender and so on. The hardest part I have
is deciding the best design structure for time depentant data?

Advise?

Thanks
JEff.

"Derek Asirvadem" <derek@softwaregemsNOSPAMcomDOTau> wrote in message
news:47ea3760@forums-1-dub...
>> On 2008-02-21 09:42:33 +1100, "M. Searer" <nospam@nospam.com> said:
>>
>> I know a lot of people use crystal for either their standard reporting
>> and/or custom client reports rather than use PB/Infomaker ... For those
>> of you using Crystal (or other reporting tools), my question is why?
>
> Here is our approach. Dozens of full implementations plus our own very
> large Ivestment Mgmt app.
>
> 1 The days of the database being only accessible by, or heavily dependent
> on, the app, are long gone. We follow Open Architecture standards, in
> essence, that means the database is entirely independent of the app. In
> our vertical (banks & finance), custs need that reassurance, if not
> compliance. They own the data (database) forever, but the apps that sit
> on top of it come and go.
>
> 2 That means true Relational DBMS, Twelve Rules (compliance grid due to
> HP requirements), 4NF Normalisation, plus High Performance structures.
> The users, but not the developers, get views.
>
> 3 All xacts are sprocs; no direct updates allowed, for performance,
> integrity and security reasons. The xacts are logical business functions
> like "add order" implemented to OLTP & ACID standards, never "insert a
> row". These principles allow HP and scaleability, and have no deadlocks.
> It is pedestrian to exec the one xact/sproc from both PB (inhouse Client
> app) and EAServer (middleware hosting a web-facing app) to perform the
> single business function and update the database. The java caller needs
> an additional "wrapper" sproc for the xact/sproc.
>
> 4 Therefore we do not tell them what they should/must use for reporting.
> Usually they already have a few licensed tools. Horses for courses.
> Depending on whether the user is a simpleton, or the report is complex, or
> they need drill-down, pivot, OLAP, etc. Anything will do, from Excel to
> Crystal Reports to BusinessObjects (which we do NOT push). CR is the most
> common request by a long shot. The point is, there is no real "report
> building" after implementation. Users these days are quite used to having
> many windows open at the same time, to view data via different methods,
> and to update it via a single [PB] app/window.
>
> 5 Due to the strict Normalisation, gathering info for "complex" reports
> is not complex, and very few report sprocs are required. Likewise tempdb
> is not overused, views do not have to be constructed and built, the views
> are straight joins.
>
> 6 PB is used for the entire inhouse Client app. All drop-downs, working
> grids (for whatever the user has to scan through to do their work), etc
> are DataWindows. No reporting from PB except to print any DataWindow with
> a bit of filtering and a bit of smarts, which uses a (our own) PFC
> definition. That is one object for the app, not per DataWindow.
>
> 7 Data Dictionary. For smaller Dbs, a syscomments entry for every column
> is usually enough (which is available from the report tool; pbcat etc is
> the wrong place). For larger Dbs, a full DD is demanded, and that too in
> the tool of choice by the customer, because that is where they are going
> to need it: for a big BO implementation, we have built the Universe; for
> others we have built the DD likewise in the reporting tool or
> PowerDesigner or ERwin (you won't believe how many people still have it).
> Again the true normalisation makes this exercise straight-forward and
> uncomplicated, and probably more important, easy to change.
>
> BTW, wearing my other hat as P&T expert, after scores of assignments, I
> can categorically tell you that incorrect Normalisation or lack of
> Normalisation (masquerading as "denormalised for performance") is the
> single biggest error that app/Db designers make, and it affects every area
> of the app/Db. Correct Normalisation makes a smaller, much faster Db,
> certainly with more relationships (FKs), every time.
>
> Incid. The big app is set up with a BO Universe, as that was demanded by
> the first cust; we are replacing that with CR in the next version. It
> does not require an Universe (great for overcoming the limitations of an
> unnormalised filing system), and BO is prohibitively expensive. They have
> acquired CR for the client list and to hit people like us.
> --
> Regards
> Derek Asirvadem
> Director / Senior Sybase DBA / Information Architect
> Copyright © 2008 Software Gems Pty Ltd
> Sybase BSA Partner
>


Derek Asirvadem Posted on 2008-03-27 04:23:18.0Z
From: Derek Asirvadem <derek@softwaregemsNOSPAMcomDOTau>
Organization: Software Gems Pty Ltd
Newsgroups: sybase.public.commercial-isv.general
Message-ID: <47eb2134@forums-1-dub>
References: <47bcacd9$1@forums-1-dub> <47ea3760@forums-1-dub> <47ea4804$1@forums-1-dub>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Reporting
User-Agent: Unison/1.7.7
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 26 Mar 2008 20:23:18 -0800
X-Trace: forums-1-dub 1206591798 10.22.241.152 (26 Mar 2008 20:23:18 -0800)
X-Original-Trace: 26 Mar 2008 20:23:18 -0800, vip152.sybase.com
Lines: 142
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:94
Article PK: 103814


> On 2008-03-26 23:56:36 +1100, "jeff" <jhersey at allnorth dottt com> said:
>
> The biggest hurdle with normalization I've encountered is when there is
> time dependency of data.
>
> Advise?

Just BTW, I welcome this kind of question, because the problem gets
discussed and clarified, and the solution gets known by the readership.

Context

There are design criteria other than Normalisation, that also need to
be considered. You have to get to the absolute truth about each entity
first (Normalisation), then enhance it or reduce it second (Design
Practicality), according to whether you are providing a full and
elaborate implementation (Full 4NF) or a Simplified one. But do not
combine the two steps, keep them separate, and in the correct sequence.
The Full 4NF implementation is demanded if you intend to allow the Db
to grow logically, which means added tables and columns, because it
eases that; the Simplified implementation is fine if you are providing
a fixed price solution with declared conditions.

Another way of stating that is, Normalisation is done in iterations (I
am do not mean 1NF/2NF/3NF iterations here) ... just how many
iterations (and therefore how Normalised) do you want to perform ? The
"Address" discussion point is a good example.

Another demand when you are designing Dbs, is that you must entirely
divorce yourself from the app, the proograms, the reports; and
concentrate on the data and the relationships only. Often DB designers
come from a solution or programming background and have pre-determined
ideas of what the data should look like (to prove the solution). It
cannot be emphaised enough, that the design rules and strategy which
must be applied to dat vs program, are completely different.

> Example...
> Patient Demographics table stores POSTAL CODE
> Encounters table stores visit to an institution / facility.
> ---------------
> a patient's POSTAL CODE can change over time ... but it is important
> for reporting that we know the postal code for each encounter.

You have just identified the Fact relevant to Normalisation.

> Just because a patient moves, does that mean their history moves too ->
> spacial representation of data / disease tracking?

Absolutely not, that would be an error.

> So, in a normalize approach would you ...
>
> 1. Store Postal Code in Patient Table.

Error, that will cause the incorrect spatial identification when
reporting historic encounters. PatientPK <=> PostalCode is NOT 1:1.

> 2. Store a 'log'of postal codes with and effective and expiry date.

That is not a "log". You actually have a historic Db, with historic
data (related to more static Reference data); you have to maintain th
eintegrity of the historic data (related to each other). Alternately,
if that is considered a "log", then the Encounter is also a "log".

> 3. when needed, get the postal code for each encounter from the postal
> code log table.
> or
> 4. would you just put the current postal code in to the encounter table?

Simplified = (4). And declare the limit that "the historic PostalCode
is accurate, but the relation between historic Patient and Encounter is
lost".

Full 4NF = (3). No limitations. But I would call the table PersonAddress.


> This is similar to name, address, gender and so on.

Not true.

1 In a reasonable Normalised implementation, the Address table will
be one of the "highest" reference tables, "higher" than Person.
Addresses (the physical building/house//apartment) do not change all
the time; the Person residing in the address does. Therefore Person is
a child of Address, with the AddressPK as an FK in Person (if you need
just the current address for Person). The exact opposite of what most
people implement. That is a solid Normalised Fact, in that particular
iteration, end of story.

Now if you need to keep historical Addresses for Persons, then you need
an addition table PersonAddress which simply resolves the many-to-many
rship between Person and [historical] Address. Whereas if you had the
common implementation (Address is a child of Person), and expanded that
to include the history (multiple Addresses per Person), you would end
up with massive physical duplication in the Address table. That is, in
fact an understandable extension of what was incorrect Normalisation to
begin with. You might then have to correct the duplication due to
resource demand, but if you do not have a Db Normalisation context, you
will not identify the Fact that Address is unnormalised, normalise it
(now you have a PK per discreet physical address), create the demanded
many-to-many table, and then use it to marry AddressPK to the PersonPK.

2 Gender is simple. It is always a true Reference table, with an FK
in the Person table. This allows you to entertain unnatural genders
and gender changes.

(But it should be said, in eloborate health systems I have enhanced,
there is a fairly strong identification requirement, so Persons are
often treated as a single gender, and changing that demands a new
PersonId (for the same Person with the new gender) .)

3 Name needs a decision regarding the long term intent of your Person
table in the context of you rsystem. Where the historical name does
not need to be recorded or not; how far do you want to go. It is no
big deal to state the limit the "the system does not have the facility
to record historical names" if that was not in the inital requirement
spec; but it is a big deal if your system is a marriage register.

> The hardest part I have is deciding the best design structure for time
> depentant data?

As I touched on before, you need to categorise the tables properly:
• true Reference
• Transaction Reference
• Transaction
• Transaction Detail
• Historic
And then maintain the integrity bewteen them appropriately: historic
facts across dimension must resolve correctly (which is what you are
seeking in your post).

Maybe it is not so clear in this example, but the point is, if the Db
were truly Normalised as above (a) you CAN change it or expand it
easily and (b) the expansion will not be further incorrect layers on
top of an incorrect initial implementation.
--
Regards
Derek Asirvadem
Director / Senior Sybase DBA / Information Architect
Copyright © 2008 Software Gems Pty Ltd
Sybase BSA Partner


Derek Asirvadem Posted on 2008-03-31 02:37:03.0Z
From: Derek Asirvadem <derek.asirvadem@gmailDOTcom>
Organization: Software Gems Pty Ltd
Newsgroups: sybase.public.commercial-isv.general
Message-ID: <47f04e4e@forums-1-dub>
References: <47bcacd9$1@forums-1-dub> <47ea3760@forums-1-dub> <47ea4804$1@forums-1-dub> <47eb2134@forums-1-dub>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Reporting
User-Agent: Unison/1.7.7
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 30 Mar 2008 18:37:03 -0800
X-Trace: forums-1-dub 1206931023 10.22.241.152 (30 Mar 2008 18:37:03 -0800)
X-Original-Trace: 30 Mar 2008 18:37:03 -0800, vip152.sybase.com
Lines: 28
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:102
Article PK: 103820

On 2008-03-27 15:23:18 +1100, Derek Asirvadem
<derek@softwaregemsNOSPAMcomDOTau> said:

> 1 In a reasonable Normalised implementation, the Address table will
> be one of the "highest" reference tables, "higher" than Person.
> Addresses (the physical building/house//apartment) do not change all
> the time; the Person residing in the address does. Therefore Person is
> a child of Address, with the AddressPK as an FK in Person (if you need
> just the current address for Person). The exact opposite of what most
> people implement. That is a solid Normalised Fact, in that particular
> iteration, end of story.

In case it is not obvious. If you have an address for the Institution
table, then one for the Order table, say BillTo and ShipTo, these
addresses would all get Normalised into the Addrees table, with FKs in
the required tables; or a associative table if historic Adresses are
required therein.

That's why it is one of the highestreference tabes, higher than the
table[s] it has an FK to.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright © 2008 Software Gems Pty Ltd
Quality Standards = Zero Maintenance + Zero Surprises
Performance Standards = Predictability + Scaleability


Breck Carter [sqlanywhere.blogspot.com] Posted on 2008-03-31 07:01:55.0Z
From: "Breck Carter [sqlanywhere.blogspot.com]" <NOSPAM__breck.carter@gmail.com>
Newsgroups: sybase.public.commercial-isv.general
Subject: Re: Reporting
Organization: RisingRoad Professional Services
Reply-To: NOSPAM__breck.carter@gmail.com
Message-ID: <nd21v3d6j8t0r1i9v55tovnf3ig9k6oh2g@4ax.com>
References: <47bcacd9$1@forums-1-dub> <47ea3760@forums-1-dub> <47ea4804$1@forums-1-dub> <47eb2134@forums-1-dub> <47f04e4e@forums-1-dub>
X-Newsreader: Forte Agent 2.0/32.640
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 30 Mar 2008 23:01:55 -0800
X-Trace: forums-1-dub 1206946915 10.22.241.152 (30 Mar 2008 23:01:55 -0800)
X-Original-Trace: 30 Mar 2008 23:01:55 -0800, vip152.sybase.com
Lines: 49
X-Authenticated-User: TeamSybase
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:103
Article PK: 103822

When you say "move all the address data to a single table" has
something to do with normalization, which of the five forms are you
referring to? That's not a rhetorical question, I really want to know
what your talking about.

I'm asking this because it feels more like object orientation
(encapsulation etc) than anything to do with normalization. In
particular, I'm having a hard time imagining a primary key for address
that isn't artificially generated.

If you are saying that shipping address and billing address are a
repeating group violating 1NF, I claim not, they are different
concepts. If there were multiple shipping addresses, and multiple
billing addresses, then those might be candidates for separate
tables... but they are dependent on the parent table (person,
whatever), not the other way around.

Breck


On 30 Mar 2008 18:37:03 -0800, Derek Asirvadem

<derek.asirvadem@gmailDOTcom> wrote:

>On 2008-03-27 15:23:18 +1100, Derek Asirvadem
><derek@softwaregemsNOSPAMcomDOTau> said:
>
>> 1 In a reasonable Normalised implementation, the Address table will
>> be one of the "highest" reference tables, "higher" than Person.
>> Addresses (the physical building/house//apartment) do not change all
>> the time; the Person residing in the address does. Therefore Person is
>> a child of Address, with the AddressPK as an FK in Person (if you need
>> just the current address for Person). The exact opposite of what most
>> people implement. That is a solid Normalised Fact, in that particular
>> iteration, end of story.
>
>In case it is not obvious. If you have an address for the Institution
>table, then one for the Order table, say BillTo and ShipTo, these
>addresses would all get Normalised into the Addrees table, with FKs in
>the required tables; or a associative table if historic Adresses are
>required therein.
>
>That's why it is one of the highestreference tabes, higher than the
>table[s] it has an FK to.

--
Breck Carter http://sqlanywhere.blogspot.com/

RisingRoad SQL Anywhere and MobiLink Professional Services
breck.carter@risingroad.com


Derek Asirvadem Posted on 2008-04-01 06:55:18.0Z
From: Derek Asirvadem <derek.asirvadem@gmailDOTcom>
Organization: Software Gems Pty Ltd
Newsgroups: sybase.public.commercial-isv.general
Message-ID: <47f1dc55@forums-1-dub>
References: <47bcacd9$1@forums-1-dub> <47ea3760@forums-1-dub> <47ea4804$1@forums-1-dub> <47eb2134@forums-1-dub> <47f04e4e@forums-1-dub> <nd21v3d6j8t0r1i9v55tovnf3ig9k6oh2g@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Reporting
User-Agent: Unison/1.7.7
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 31 Mar 2008 22:55:18 -0800
X-Trace: forums-1-dub 1207032918 10.22.241.152 (31 Mar 2008 22:55:18 -0800)
X-Original-Trace: 31 Mar 2008 22:55:18 -0800, vip152.sybase.com
Lines: 61
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:104
Article PK: 103823


> On 2008-03-31 18:01:55 +1100, "Breck Carter [sqlanywhere.blogspot.com]"
> <NOSPAM__breck.carter@gmail.com> said:
>
> When you say "move all the address data to a single table" has
> something to do with normalization, which of the five forms are you
> referring to?
>
> If you are saying that shipping address and billing address are a
> repeating group violating 1NF, I claim not, they are different
> concepts.

Agreed

> If there were multiple shipping addresses, and multiple
> billing addresses, then those might be candidates for separate
> tables... but they are dependent on the parent table (person,
> whatever), not the other way around.

Agreed. But you are applying strict Normalisation (correctly) in the
context of the the early proponents, only.

But these days Normalisation has matured or progressed. 4NF Dbs have
been around for twnty years, and due to the app changes, org changes,
expansions of various kinds, thyey have profgressed (well at least mine
have). It is not 5NF, it is a progression of 4NF on a Db-wide scale.
What do you do when you notice that you have five instances of 8
address columns stored in diff tables ? Then two of them have to be
made to comply with an external (street) directory/registry service you
are going to connect the app to in the next release ? Although the
Normalisation is correct, you still notice that you have repeating
groups that need to be managed/changed together, and you do not want to
do that in five places. You have some experience with encapsulation/OO
(which is the app anyway). I see it as a true progression to remove
the five instances to an Address table and FK to the five instances.

Yes, you divorce yourself a bit from the original location but not
really. You have improved the implementation but you have not broken
Normalisation rules, you have added to it.

> I'm having a hard time imagining a primary key for address
> that isn't artificially generated.

Well the Address table is now "higher" in terms of reference than
Person, Institution, Order, et al. It is a PK that is not dependent on
those, it is independent. Classically, the parents of Address will be
Country, State/Province (within Country) ... maybe a Postcode (eg. in
Australia it is required as postcode = suburb; in England and Canada,
no sir). Etc. Therefore given that we usually hit the "reasonable
limit" of a normalised compound key (eg 5 components), and considering
that we are going to carry that PK all over the shore, this is a good
place to implement an alternate unique key. I like Integer (faster) so
that's what I do. If you randomise it; or use a CountryCode+AddressId
as the PK, you lose the "next sequential number" problem.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright © 2008 Software Gems Pty Ltd
Quality Standards = Zero Maintenance + Zero Surprises
Performance Standards = Predictability + Scaleability


Derek Asirvadem Posted on 2008-04-01 11:22:47.0Z
From: Derek Asirvadem <derek.asirvadem@gmailDOTcom>
Organization: Software Gems Pty Ltd
Newsgroups: sybase.public.commercial-isv.general
Message-ID: <47f21b07@forums-1-dub>
References: <47bcacd9$1@forums-1-dub> <47ea3760@forums-1-dub> <47ea4804$1@forums-1-dub> <47eb2134@forums-1-dub> <47f04e4e@forums-1-dub> <nd21v3d6j8t0r1i9v55tovnf3ig9k6oh2g@4ax.com> <47f1dc55@forums-1-dub>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Reporting
User-Agent: Unison/1.7.7
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 1 Apr 2008 03:22:47 -0800
X-Trace: forums-1-dub 1207048967 10.22.241.152 (1 Apr 2008 03:22:47 -0800)
X-Original-Trace: 1 Apr 2008 03:22:47 -0800, vip152.sybase.com
Lines: 16
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:105
Article PK: 103824


> On 2008-04-01 17:55:18 +1100, Derek Asirvadem
> <derek.asirvadem@gmailDOTcom> said:

That's what I meant by "iterations" of Normalisationm, as opposed to
fifth and sixth Normal Form.

WRT strict Normalisation, AFAIC, you only need 4NF for a true RDBMS.
Then progress further.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright © 2008 Software Gems Pty Ltd
Quality Standards = Zero Maintenance + Zero Surprises
Performance Standards = Predictability + Scaleability


Breck Carter [sqlanywhere.blogspot.com] Posted on 2008-04-01 12:46:31.0Z
From: "Breck Carter [sqlanywhere.blogspot.com]" <NOSPAM__breck.carter@gmail.com>
Newsgroups: sybase.public.commercial-isv.general
Subject: Re: Reporting
Organization: RisingRoad Professional Services
Reply-To: NOSPAM__breck.carter@gmail.com
Message-ID: <28b4v3tbu9cpn14v702dgvsa5geev2khle@4ax.com>
References: <47bcacd9$1@forums-1-dub> <47ea3760@forums-1-dub> <47ea4804$1@forums-1-dub> <47eb2134@forums-1-dub> <47f04e4e@forums-1-dub> <nd21v3d6j8t0r1i9v55tovnf3ig9k6oh2g@4ax.com> <47f1dc55@forums-1-dub> <47f21b07@forums-1-dub>
X-Newsreader: Forte Agent 2.0/32.640
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 1 Apr 2008 04:46:31 -0800
X-Trace: forums-1-dub 1207053991 10.22.241.152 (1 Apr 2008 04:46:31 -0800)
X-Original-Trace: 1 Apr 2008 04:46:31 -0800, vip152.sybase.com
Lines: 23
X-Authenticated-User: TeamSybase
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:106
Article PK: 103825

I once worked for a boss (Helge Knudsen on Amdahl's Huron Project
http://hopl.murdoch.edu.au/showlanguage2.prx?exp=7530 ) who claimed
that 5NF didn't exist, was the work of an overheated researcher :)

Breck

On 1 Apr 2008 03:22:47 -0800, Derek Asirvadem

<derek.asirvadem@gmailDOTcom> wrote:

>> On 2008-04-01 17:55:18 +1100, Derek Asirvadem
>> <derek.asirvadem@gmailDOTcom> said:
>
>That's what I meant by "iterations" of Normalisationm, as opposed to
>fifth and sixth Normal Form.
>
>WRT strict Normalisation, AFAIC, you only need 4NF for a true RDBMS.
>Then progress further.

--
Breck Carter http://sqlanywhere.blogspot.com/

RisingRoad SQL Anywhere and MobiLink Professional Services
breck.carter@risingroad.com


Derek Asirvadem Posted on 2008-04-02 06:50:48.0Z
From: Derek Asirvadem <derek.asirvadem@gmailDOTcom>
Organization: Software Gems Pty Ltd
Newsgroups: sybase.public.commercial-isv.general
Message-ID: <47f32cc6@forums-1-dub>
References: <47bcacd9$1@forums-1-dub> <47ea3760@forums-1-dub> <47ea4804$1@forums-1-dub> <47eb2134@forums-1-dub> <47f04e4e@forums-1-dub> <nd21v3d6j8t0r1i9v55tovnf3ig9k6oh2g@4ax.com> <47f1dc55@forums-1-dub> <47f21b07@forums-1-dub> <28b4v3tbu9cpn14v702dgvsa5geev2khle@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Reporting
User-Agent: Unison/1.7.7
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 1 Apr 2008 22:50:48 -0800
X-Trace: forums-1-dub 1207119048 10.22.241.152 (1 Apr 2008 22:50:48 -0800)
X-Original-Trace: 1 Apr 2008 22:50:48 -0800, vip152.sybase.com
Lines: 23
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:107
Article PK: 103826


> On 2008-04-01 23:46:31 +1100, "Breck Carter [sqlanywhere.blogspot.com]"
> <NOSPAM__breck.carter@gmail.com> said:
>
> I once worked for a boss (Helge Knudsen on Amdahl's Huron Project
> http://hopl.murdoch.edu.au/showlanguage2.prx?exp=7530 ) who claimed
> that 5NF didn't exist, was the work of an overheated researcher :)

I am definitely with Helge. Just that those who are earnestly trying
to perform Normalisation by the book, but who have not worked with a
large DB over many years of maintenance/expansion, often quote the
proverbial 5NF etc. (But that is infinitely better than those who do
not Normalise at all !) Architecture, sensibility and practicality
have got to prevail over The Book.

BTW I lived in Ca for twelve years, and still have a soft spot for it.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright © 2008 Software Gems Pty Ltd
Quality Standards = Zero Maintenance + Zero Surprises
Performance Standards = Predictability + Scaleability


Breck Carter [sqlanywhere.blogspot.com] Posted on 2008-04-02 10:28:45.0Z
From: "Breck Carter [sqlanywhere.blogspot.com]" <NOSPAM__breck.carter@gmail.com>
Newsgroups: sybase.public.commercial-isv.general
Subject: Re: Reporting
Organization: RisingRoad Professional Services
Reply-To: NOSPAM__breck.carter@gmail.com
Message-ID: <vqn6v3pcv3nn3sdlul5p699k45smt2lmst@4ax.com>
References: <47bcacd9$1@forums-1-dub> <47ea3760@forums-1-dub> <47ea4804$1@forums-1-dub> <47eb2134@forums-1-dub> <47f04e4e@forums-1-dub> <nd21v3d6j8t0r1i9v55tovnf3ig9k6oh2g@4ax.com> <47f1dc55@forums-1-dub> <47f21b07@forums-1-dub> <28b4v3tbu9cpn14v702dgvsa5geev2khle@4ax.com> <47f32cc6@forums-1-dub>
X-Newsreader: Forte Agent 2.0/32.640
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 2 Apr 2008 02:28:45 -0800
X-Trace: forums-1-dub 1207132125 10.22.241.152 (2 Apr 2008 02:28:45 -0800)
X-Original-Trace: 2 Apr 2008 02:28:45 -0800, vip152.sybase.com
Lines: 30
X-Authenticated-User: TeamSybase
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:108
Article PK: 103827

Ca the state, or Ca the country? I'm guessing the latter since that's
where Helge/Huron were based, at least when I was on the project
(employee number three :)

Breck

On 1 Apr 2008 22:50:48 -0800, Derek Asirvadem

<derek.asirvadem@gmailDOTcom> wrote:

>> On 2008-04-01 23:46:31 +1100, "Breck Carter [sqlanywhere.blogspot.com]"
>> <NOSPAM__breck.carter@gmail.com> said:
>>
>> I once worked for a boss (Helge Knudsen on Amdahl's Huron Project
>> http://hopl.murdoch.edu.au/showlanguage2.prx?exp=7530 ) who claimed
>> that 5NF didn't exist, was the work of an overheated researcher :)
>
>I am definitely with Helge. Just that those who are earnestly trying
>to perform Normalisation by the book, but who have not worked with a
>large DB over many years of maintenance/expansion, often quote the
>proverbial 5NF etc. (But that is infinitely better than those who do
>not Normalise at all !) Architecture, sensibility and practicality
>have got to prevail over The Book.
>
>BTW I lived in Ca for twelve years, and still have a soft spot for it.

--
Breck Carter http://sqlanywhere.blogspot.com/

RisingRoad SQL Anywhere and MobiLink Professional Services
breck.carter@risingroad.com


Derek Asirvadem Posted on 2008-04-02 11:01:08.0Z
From: Derek Asirvadem <derek.asirvadem@gmailDOTcom>
Organization: Software Gems Pty Ltd
Newsgroups: sybase.public.commercial-isv.general
Message-ID: <47f36773@forums-1-dub>
References: <47bcacd9$1@forums-1-dub> <47ea3760@forums-1-dub> <47ea4804$1@forums-1-dub> <47eb2134@forums-1-dub> <47f04e4e@forums-1-dub> <nd21v3d6j8t0r1i9v55tovnf3ig9k6oh2g@4ax.com> <47f1dc55@forums-1-dub> <47f21b07@forums-1-dub> <28b4v3tbu9cpn14v702dgvsa5geev2khle@4ax.com> <47f32cc6@forums-1-dub> <vqn6v3pcv3nn3sdlul5p699k45smt2lmst@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Reporting
User-Agent: Unison/1.7.7
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 2 Apr 2008 03:01:08 -0800
X-Trace: forums-1-dub 1207134068 10.22.241.152 (2 Apr 2008 03:01:08 -0800)
X-Original-Trace: 2 Apr 2008 03:01:08 -0800, vip152.sybase.com
Lines: 17
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:109
Article PK: 103831


> On 2008-04-02 21:28:45 +1100, "Breck Carter [sqlanywhere.blogspot.com]"
> <NOSPAM__breck.carter@gmail.com> said:
>
> Ca the state, or Ca the country? I'm guessing the latter since that's
> where Helge/Huron were based, at least when I was on the project
> (employee number three :)

That's good ole TO on Lake Ontario, UfT, Ryerson and Guelp if you
fancied the drive.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright © 2008 Software Gems Pty Ltd
Quality Standards = Zero Maintenance + Zero Surprises
Performance Standards = Predictability + Scaleability


M. Searer Posted on 2008-03-26 14:44:38.0Z
From: "M. Searer" <nospam@nospam.com>
Newsgroups: sybase.public.commercial-isv.general
References: <47bcacd9$1@forums-1-dub> <47ea3760@forums-1-dub>
Subject: Re: Reporting
Lines: 98
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <47ea6156$1@forums-1-dub>
Date: 26 Mar 2008 06:44:38 -0800
X-Trace: forums-1-dub 1206542678 10.22.241.152 (26 Mar 2008 06:44:38 -0800)
X-Original-Trace: 26 Mar 2008 06:44:38 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:92
Article PK: 103812

4) Yes, most DBs these days will pretty much allow access via any tool. We
have some customers using MS Access to do some of their reporting, others use
cognos, .... Typically people will use what they are most comfortable with. We
push infomaker/dw reporting since we have added a lot of standard report
capabilities to our reporting subsystem that any report, including custom
reports built in infomaker, can take advantage of.

7) We don't use syscomments as it is a database specific implementation (our app
runs on 4 different databases). The other thing for our app is that our
customers expect a data dictionary to be already setup for them (or at least I
would expect it if I was a customer). The pbcat tables work well for that (at
least for our app), plus it is already implemented for us in infomaker, pb, and
powerdesigner. For use outside of PB/Infomaker, (CR especially), I don't even
know what options would be available. It has been awhile since I used CR.

"Derek Asirvadem" <derek@softwaregemsNOSPAMcomDOTau> wrote in message
news:47ea3760@forums-1-dub...
>> On 2008-02-21 09:42:33 +1100, "M. Searer" <nospam@nospam.com> said:
>>
>> I know a lot of people use crystal for either their standard reporting and/or
>> custom client reports rather than use PB/Infomaker ... For those of you
>> using Crystal (or other reporting tools), my question is why?
>
> Here is our approach. Dozens of full implementations plus our own very large
> Ivestment Mgmt app.
>
> 1 The days of the database being only accessible by, or heavily dependent on,
> the app, are long gone. We follow Open Architecture standards, in essence,
> that means the database is entirely independent of the app. In our vertical
> (banks & finance), custs need that reassurance, if not compliance. They own
> the data (database) forever, but the apps that sit on top of it come and go.
>
> 2 That means true Relational DBMS, Twelve Rules (compliance grid due to HP
> requirements), 4NF Normalisation, plus High Performance structures. The
> users, but not the developers, get views.
>
> 3 All xacts are sprocs; no direct updates allowed, for performance, integrity
> and security reasons. The xacts are logical business functions like "add
> order" implemented to OLTP & ACID standards, never "insert a row". These
> principles allow HP and scaleability, and have no deadlocks. It is pedestrian
> to exec the one xact/sproc from both PB (inhouse Client app) and EAServer
> (middleware hosting a web-facing app) to perform the single business function
> and update the database. The java caller needs an additional "wrapper" sproc
> for the xact/sproc.
>
> 4 Therefore we do not tell them what they should/must use for reporting.
> Usually they already have a few licensed tools. Horses for courses.
> Depending on whether the user is a simpleton, or the report is complex, or
> they need drill-down, pivot, OLAP, etc. Anything will do, from Excel to
> Crystal Reports to BusinessObjects (which we do NOT push). CR is the most
> common request by a long shot. The point is, there is no real "report
> building" after implementation. Users these days are quite used to having
> many windows open at the same time, to view data via different methods, and to
> update it via a single [PB] app/window.
>
> 5 Due to the strict Normalisation, gathering info for "complex" reports is
> not complex, and very few report sprocs are required. Likewise tempdb is not
> overused, views do not have to be constructed and built, the views are
> straight joins.
>
> 6 PB is used for the entire inhouse Client app. All drop-downs, working
> grids (for whatever the user has to scan through to do their work), etc are
> DataWindows. No reporting from PB except to print any DataWindow with a bit
> of filtering and a bit of smarts, which uses a (our own) PFC definition. That
> is one object for the app, not per DataWindow.
>
> 7 Data Dictionary. For smaller Dbs, a syscomments entry for every column is
> usually enough (which is available from the report tool; pbcat etc is the
> wrong place). For larger Dbs, a full DD is demanded, and that too in the tool
> of choice by the customer, because that is where they are going to need it:
> for a big BO implementation, we have built the Universe; for others we have
> built the DD likewise in the reporting tool or PowerDesigner or ERwin (you
> won't believe how many people still have it). Again the true normalisation
> makes this exercise straight-forward and uncomplicated, and probably more
> important, easy to change.
>
> BTW, wearing my other hat as P&T expert, after scores of assignments, I can
> categorically tell you that incorrect Normalisation or lack of Normalisation
> (masquerading as "denormalised for performance") is the single biggest error
> that app/Db designers make, and it affects every area of the app/Db. Correct
> Normalisation makes a smaller, much faster Db, certainly with more
> relationships (FKs), every time.
>
> Incid. The big app is set up with a BO Universe, as that was demanded by the
> first cust; we are replacing that with CR in the next version. It does not
> require an Universe (great for overcoming the limitations of an unnormalised
> filing system), and BO is prohibitively expensive. They have acquired CR for
> the client list and to hit people like us.
> --
> Regards
> Derek Asirvadem
> Director / Senior Sybase DBA / Information Architect
> Copyright © 2008 Software Gems Pty Ltd
> Sybase BSA Partner
>


Derek Asirvadem Posted on 2008-03-27 06:41:35.0Z
From: Derek Asirvadem <derek.asirvadem@gmailDOTcom>
Organization: Software Gems Pty Ltd
Newsgroups: sybase.public.commercial-isv.general
Message-ID: <47eb419e@forums-1-dub>
References: <47bcacd9$1@forums-1-dub> <47ea3760@forums-1-dub> <47ea6156$1@forums-1-dub>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Reporting
User-Agent: Unison/1.7.7
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 26 Mar 2008 22:41:35 -0800
X-Trace: forums-1-dub 1206600095 10.22.241.152 (26 Mar 2008 22:41:35 -0800)
X-Original-Trace: 26 Mar 2008 22:41:35 -0800, vip152.sybase.com
Lines: 44
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:95
Article PK: 103815

BTW In my previous post, I was answering your original question,
period. I was not making a comment about Infomaker or your method.

> On 2008-03-27 01:44:38 +1100, "M. Searer" <nospam@nospam.com> said:
>
> We push infomaker/dw reporting since we have added a lot of standard
> report capabilities to our reporting subsystem that any report,
> including custom reports built in infomaker, can take advantage of.

That's great, but do you really want to be competing with the likes of
CR, BO, Cognos ? As a supplier, I do not see a substantial return on
this investment, given the report providers do ONLY that; hopefully
improving their drill-downs, navigation, performance, etc. over time.

The question I would ask is, are you supplying a closed app with closed
good reporting, or an open app with unlimited reporting ?

> 7) We don't use syscomments as it is a database specific implementation
> (our app runs on 4 different databases).

While the syscomments entry on the face of it, is Db-specific, the
point is, any tool that is capable of reporting from a SQL databases,
fishes it out and displays it to the user. It is about its utility as
a DD item via the report tool of their choice.

> The other thing for our app is that our customers expect a data
> dictionary to be already setup for them (or at least I would expect it
> if I was a customer). The pbcat tables work well for that (at least
> for our app), plus it is already implemented for us in infomaker, pb,
> and powerdesigner.

And not outside that.

> For use outside of PB/Infomaker, (CR especially), I don't even know
> what options would be available. It has been awhile since I used CR.

CR picks up the syscomments entry (additional commentary re table/column).
--
Regards
Derek Asirvadem
Director / Senior Sybase DBA / Information Architect
Copyright © 2008 Software Gems Pty Ltd
Sybase BSA Partner


M. Searer Posted on 2008-03-27 18:22:02.0Z
From: "M. Searer" <nospam@nospam.com>
Newsgroups: sybase.public.commercial-isv.general
References: <47bcacd9$1@forums-1-dub> <47ea3760@forums-1-dub> <47ea6156$1@forums-1-dub> <47eb419e@forums-1-dub>
Subject: Re: Reporting
Lines: 60
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <47ebe5ca$1@forums-1-dub>
Date: 27 Mar 2008 10:22:02 -0800
X-Trace: forums-1-dub 1206642122 10.22.241.152 (27 Mar 2008 10:22:02 -0800)
X-Original-Trace: 27 Mar 2008 10:22:02 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:100
Article PK: 103819

>>CR picks up the syscomments entry (additional commentary re table/column).
I double checked; infomaker won't - it requires the pbcat. This probably makes
sense for databases type of things that don't (or in the past didn't) support
descriptions, but it would be nice if it supported it natively.

Do you happen to know whether CR supports this for all databases (Oracle, MS
SQL, SQL Anywhere, DB2...) that support descriptions/DD? I agree that it would
be best to use a set of tables that any report writer could conceivable know
about. Every DB vendor implemented this their own way, so it is sysproperties
for ms sql, user_col_comments for oracle, etc.

"Derek Asirvadem" <derek.asirvadem@gmailDOTcom> wrote in message
news:47eb419e@forums-1-dub...
> BTW In my previous post, I was answering your original question, period. I
> was not making a comment about Infomaker or your method.
>
>> On 2008-03-27 01:44:38 +1100, "M. Searer" <nospam@nospam.com> said:
>>
>> We push infomaker/dw reporting since we have added a lot of standard report
>> capabilities to our reporting subsystem that any report, including custom
>> reports built in infomaker, can take advantage of.
>
> That's great, but do you really want to be competing with the likes of CR, BO,
> Cognos ? As a supplier, I do not see a substantial return on this investment,
> given the report providers do ONLY that; hopefully improving their
> drill-downs, navigation, performance, etc. over time.
>
> The question I would ask is, are you supplying a closed app with closed good
> reporting, or an open app with unlimited reporting ?
>
>> 7) We don't use syscomments as it is a database specific implementation (our
>> app runs on 4 different databases).
>
> While the syscomments entry on the face of it, is Db-specific, the point is,
> any tool that is capable of reporting from a SQL databases, fishes it out and
> displays it to the user. It is about its utility as a DD item via the report
> tool of their choice.
>
>> The other thing for our app is that our customers expect a data dictionary to
>> be already setup for them (or at least I would expect it if I was a
>> customer). The pbcat tables work well for that (at least for our app), plus
>> it is already implemented for us in infomaker, pb, and powerdesigner.
>
> And not outside that.
>
>> For use outside of PB/Infomaker, (CR especially), I don't even know what
>> options would be available. It has been awhile since I used CR.
>
> CR picks up the syscomments entry (additional commentary re table/column).
> --
> Regards
> Derek Asirvadem
> Director / Senior Sybase DBA / Information Architect
> Copyright © 2008 Software Gems Pty Ltd
> Sybase BSA Partner
>


Derek Asirvadem Posted on 2008-03-28 01:45:21.0Z
From: Derek Asirvadem <derek.asirvadem@gmailDOTcom>
Organization: Software Gems Pty Ltd
Newsgroups: sybase.public.commercial-isv.general
Message-ID: <47ec4db0@forums-1-dub>
References: <47bcacd9$1@forums-1-dub> <47ea3760@forums-1-dub> <47ea6156$1@forums-1-dub> <47eb419e@forums-1-dub> <47ebe5ca$1@forums-1-dub>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Reporting
User-Agent: Unison/1.7.7
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 27 Mar 2008 17:45:21 -0800
X-Trace: forums-1-dub 1206668721 10.22.241.152 (27 Mar 2008 17:45:21 -0800)
X-Original-Trace: 27 Mar 2008 17:45:21 -0800, vip152.sybase.com
Lines: 34
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:101
Article PK: 103821


> On 2008-03-28 05:22:02 +1100, "M. Searer" <nospam@nospam.com> said:
>
>>> CR picks up the syscomments entry (additional commentary re table/column).
> I double checked; infomaker won't - it requires the pbcat. This
> probably makes sense for databases type of things that don't (or in the
> past didn't) support descriptions, but it would be nice if it supported
> it natively.
>
> Do you happen to know whether CR supports this for all databases
> (Oracle, MS SQL, SQL Anywhere, DB2...) that support descriptions/DD?

No, I don't. One exception, about 8 years ago it worked for MS-SQL/CR,
via syscomments. But they were furious that I did it that way, because
they were pushing for their own expensive DD which was then not
required.

> I agree that it would be best to use a set of tables that any report
> writer could conceivable know about. Every DB vendor implemented this
> their own way, so it is sysproperties for ms sql, user_col_comments for
> oracle, etc.

Yeah, it is a pain. The Db agnostic approach has many obstacles. If
you do the same thing you have done with your other logical functions,
you can overcome it: if SYB then write syscomments; if MS then write
sysproperties; etc. But pbcat is the wrong place, it is too
app-centric and vedor-centric.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright © 2008 Software Gems Pty Ltd
Quality Standards = Zero Maintenance + Zero Surprises
Performance Standards = Predictability + Scaleability