Showing posts with label app. Show all posts
Showing posts with label app. Show all posts

Tuesday, March 27, 2012

concate comments from different rows

Posted - 01/08/2007 : 17:36:50


Here is my example.

data
ID CommentID Comments
1 1 'app'
1 2 'le'
2 1 'or'
2 2 'an'
2 3 'ge'
3 1 'banana'

results want to get
1 apple
2 orange
3 banana

I was thinking to using the PIVOT, but as the number of row is unknown, I think it can't be used.

any help is appreciate!

I would seriously consider not doing this in SQL. It will be much easier to do in the presentation layer (and you won't have any issues with the size of the data, either)

You could build a user defined function and cursor through the comments ordered by the commentID (assuming that is the order) also, but unless you actually need the results in another SQL statement, using the presentation layer would be the best way to go

|||

I understand that you are using SQL Server 2005..

Here CTE is best solution rather than UI..

In UI you have to Loop or need to use DataViews.. It is bit expensive than SQL query..

Try the following Query it will help you..

create table comments
(
Id int,
CommentId int,
Comments varchar(100)
)
Go
Insert into comments values (1,1,'app')
Insert into comments values (1,2,'le')
Insert into comments values (2,1,'or')
Insert into comments values (2,2,'an')
Insert into comments values (2,3,'ge')
Insert into comments values (3,1,'banana')
Go
WITH JoinComment (Id,CommentId,Comments,MaxId)
as
(
Select A.id,A.CommentId,convert(varchar(8000),Comments) Comments,Max(commentId) Over (partition By Id) as maxId From Comments a
Union All
Select A.Id, A.CommentId, A.Comments + B.Comments as Comments,A.CommentId
From
Comments A Inner Join JoinComment B
On (A.CommentId+1)=B.CommentId
And A.CommentId <> B.CommentId
and B.CommentId = B.maxId
And A.Id=B.Id
)
Select Id,CommentId,Comments from JoinComment
Where CommentId=MaxId And CommentId=1

|||SET
NOCOUNT ON

DECLARE
@.T AS TABLE(y nvarchar(20) NOT NULL PRIMARY KEY)

INSERT
INTO @.T SELECT DISTINCT CommentID FROM comments
DECLARE
@.T1 AS TABLE(num int NOT NULL PRIMARY KEY)

DECLARE @.i AS int

SET @.i=1
WHILE @.i <20

BEGIN

INSERT INTO @.T1 SELECT @.i

SET @.i=@.i+1

END

DECLARE @.cols AS nvarchar(MAX), @.cols2 AS nvarchar(MAX),@.y AS nvarchar(20)

SET @.y = (SELECT MIN(y) FROM @.T)

SET @.cols = N''
SET @.cols2 = N''

WHILE @.y IS NOT NULL

BEGIN

SET @.cols = @.cols + N',['+CAST(@.y AS nvarchar(20))+N']'
SET @.cols2 = @.cols2 + N'+ coalesce(['+CAST(@.y AS nvarchar(20))+N'],'''')'

SET @.y = (SELECT MIN(y) FROM @.T WHERE y > @.y)

END

SET @.cols = SUBSTRING(@.cols, 2, LEN(@.cols))
SET @.cols2 = SUBSTRING(@.cols2, 2, LEN(@.cols2)-1)
DECLARE @.sql AS nvarchar(MAX)

SET @.sql = N'SELECT ID' + N',(' +@.cols2 + N') AS newColumn FROM (SELECT ID, CommentID, Comments FROM comments) as t

PIVOT (min(comments) FOR CommentID IN(' + @.cols + N')) AS pvt'

EXEC sp_executesql @.sql|||

Hi Terrence,

Here is my solution.

I assume that the comments table named as "z"

Also note that I'm using a user defined function named dbo.Split() which you can find its code from

http://www.kodyaz.com/forums/489/ShowThread.aspx#489

declare @.s varchar(100), @.i tinyint, @.t tinyint

select @.t = 0, @.i = min(id), @.s = CAST(@.i as varchar(5)) + '-' from z

select

@.t = case when @.i = id then 0 else 1 end,

@.s = coalesce(@.s + case when @.t = 1 then ';' + CAST(id as varchar(5)) + '-' else '' end + comments , ''),

@.i = id

from z

order by id, commentid

-- select @.s

select

SUBSTRING(strval,0, CHARINDEX('-', strval)) AS Id,

SUBSTRING(strval, CHARINDEX('-', strval) + 1, LEN(strval) - 2) AS Comment

from dbo.Split(@.s,';')

Eralper

http://www.kodyaz.com

|||As Louis pointed out, you will be better off doing this on the client side. Any server solution will perform poorly and look complicated. Is there any reason why you are storing the comments as multiple rows? How do the comments gets split across rows? What happens if the comments get edited? Do you delete all the rows and reenter them? It is best you redesign the schema to use a simple comments column of varchar(8000), varchar(max), nvarchar(4000) or text as appropriate. Suggesting a SQL solution is easy actually but it is not the right way. As you suggested, you can use PIVOT in SQL Server 2005 without dynamic SQL by fixing the maximum number of comment fragments.|||

Here is my table schema

ApplicationComment Table

-AppId int (Key)

-CommentId int(Key)

-Comments

-ModifiedDate

-ModifiedBy

What I am doing is creating a stored procedure(sp) for a report using reporting services, so I think concate the comments in a sp (rather than the presentation layer) is more appropriate.

Here is the sample data

1,1, 'This is the first comments',.....

1,2, 'This is the second comments for the application Id 1',.....

1,3,'The application is closed',.....

In the front end, the modified date, modified by and and comments are shown in a datagrid.

01/01/2007 Tester1 'This is the first comments'

01/02/2007 Tester2 'This is the second comments for the application Id 1'

In the comments summary report, what I want is this

Application ID , Comments

1, This is the first comments

This is the second comments for the application Id 1

The application is closed

2, .....

Umachandar, I am more than happy to take any suggestion that you may have... Thanks.

|||

I don't know enough about Reporting Services to comment on it's features. But these type of reports are trivial to generate in Crystal Reports for example (one I am familiar with and used in the past). You can just issue a query like:

select a.AppId, a.Comments

from ApplicationComment as a

order a.AppId, a.CommentId

And suppress repeating values in the report. That is all there is to it. You can also do simple grouping to provide a header and several detail rows kind of report. Anyway, it seems like you should ask in the Reporting Services newsgroup about how to generate such a formatted report.

You can use SQL to generate the result set like:

select pa.AppId

, pa.[1] + coalesce(pa.[2], '') + coalesce(pa.[3], '')...... as Comments

from (select AppId, CommentId, Comments from ApplicationComment) as a

pivot (min(a.Comments) for a.CommentId in ([1], [2], [3], ....

/* fix some maximum number here. 100 or 1000 it doesn't matter*/

)) as pa

order by pa.AppId

Note that you may have to cast one of the expressions for the Comments column to varchar(max) or nvarchar(max) if the maximum length of the comments can exceed 8000 bytes. Also, the performance of the query will be poor due to the string concatenations and it will be directly proportional to the number of rows in the table & number of comments per id.

|||

Here is my solution using UDF as it looks more clearer for me, but as most of the expert explains don't do in the server side.

I finally put that in the presentation layer because of the poor perfermance.

create function dbo.uf_ConcateComments(

@.ApplicationId INT

)

returns varchar(max)

as

begin

declare

@.Return as VARCHAR(max),

@.newline as char(2)

set @.Return = ''

set @.newline = char(13) + char(10)

select

@.Return = @.Return + @.newline + @.newline +

cast(DATEPART(dd,t.CreatedDate)as varchar(2)) + '/' +

cast(DATEPART(mm,t.CreatedDate)as varchar(2)) + '/' +

cast(DATEPART(yyyy,t.CreatedDate)as varchar(4)) + ' ' +

t.CreatedBy + ': ' + t.Comments

from

dbo.ApplicationComment t

where t.ApplicationId = @.ApplicationId

order by

t.CommentID

return (@.Return)

end

GO

In a store procedure, do this.

SELECT

ApplicationId,

dbo.uf_ConcateComments(ApplicationId) as concateComments

from

Application x

ORDER BY

ApplicationId desc

|||

>> I finally put that in the presentation layer because of the poor perfermance.<<

That is the best way, in my opinion, as it is very natural for the presentation layer to pass through each row individually, since this is how you end up doing it anyhow (even if you let some object built into some library handle your data)

Tuesday, March 20, 2012

Compression

Hi everyone,
I am developing a web app and wanting to store documents (doc, xls,
pdf, ppt...etc.) within the DB (MSSQL). Is it advisable in general (I
don't know exactly how big the docs are going to be) to compress the
files before putting them into the DB? How does this affect Full Text
Searching? On a wider note what's the attitude of people in terms of
storing documents in the DB versus on the file system. There seems to
be a lot of differing opinions. Any links to resources would be most
appreciated.
Thanks for your help in advance.
Jose
Jose,
First of all, can I assume that you are using SQL Server 2000? If so, could
you post the full output of: SELECT @.@.version -- as this is very help info
in understanding SQL FTS issues.
Secondly, what exactly do you mean by "compress[ing] the files before
putting them into the DB?" Do you mean to store them as ZIP files in columns
defined with the IMAGE datatype? or are you thinking about placing the FT
Catalog folder (SQL00060005) & files on a compressed drive. As for the
latter, I've not done any testing with compressed drive, but Hilary Cotter
has and from past postings on this subject, he's indicated that the
performance gains is mimumal. As for the former, you will need to purchase a
3rd Party IFilter for the WinZIP ZIP file format and then assuming you are
using SQL Server 2000, you can store the zip files in an IMAGE datatype and
define a "file extension" column that will have the value of "zip" and the
ZIP IFilter will be called by the MSSearch and the mssdmn (Search Filter
Daemon) processes to FT Index the contents of the zip file that contains MS
Word documents. You can purchase the ZIP IFilter from either of the
following two vendors:
http://www.4-share.com/content/products.htm
http://www.ifiltershop.com/zipfilter.html
I've personally have been using the 4-Share ZIP IFilter for over a year and
find it works very well for me.
As for "storing documents in the DB versus on the file system", this is very
much a open and very actively discussed subject, below is one past posting
I've made on this subject with links included...
"There are many issues related to storing the files on disk (faster access,
easy copy/move, etc.) vs. storing the files in the database (transaction
control, change control, audit of changes, etc) than just efficiency and
scalability, although, those are important points... There is a ASPFAQ
website that has a number of references
(http://www.aspfaq.com/show.asp?id=2149) and links to KB articles (I've not
checked them all), but one major reason for storing the files in a SQL
Server table's column defined with an IMAGE datatype, is that in SQL Server
2000 you can take advantage of the new Full-Text Search (FTS) feature to FT
Index the contents of supported file types, primarily MS Office, HTML and
3rd party IFilter's like Adobe's PDF files.
As this is one of those FAQ type questions that have been known to start
religious wars or at the very least a flame war, and while Sharon didn't ask
about other application issues that this question often generates as it is
often an open-ended question, i.e., one that never seems to be answered to
everyone's satisfactions as it usually "depends" upon the application or
upon how one defines the word "best"...
As for the Terra Server, checkout the "about page"
(http://terraserver-usa.com/about.aspx?n=AboutBody) on the site that
explains how MS and others did it and yes, they used the IMAGE datatype,
specifically
http://terraserver-usa.com/about.asp...utTechDbschema (The Imagery table
contains the "blob" [image] field where the imagery data is stored.
Jose, depending upon how many files you have, how frequently they change,
how large they are, what the app is, etc. you may want to review the Terra
Server web site and consider the following rule of thumb that they used:
< 1 million images or big images (> 1MB) put them in the file system.
> 1 million and < 1 MB images, put them in SQL Server.
Note, you can also use "Text-in-Row" if the files are >7000 bytes on avg.
For everything in between, either way will work, depending upon if you need
transactional control over your files. Additionally, if you store the files
in a TEXT or IMAGE column, you can also store related metadata about that
file in SQL Server as well for increased searching capabilities. Also, and
obviously with SQL Server you get built-in support for validating the
consistency of the database, indices, backup, restore, etc. As for loading
&/or extracting the files from SQL Server there are now many methods of
doing this via BCP, BULK INSERT as well as ADO Stream DTS too, if you need
to transform your files in some manner.
Hope this helps, as the primary consideration should always be what is best
for your application...
Regards,
John
"Jose Perez" <jlpv@.totalise.co.uk> wrote in message
news:3724a9d9.0404141212.480e1630@.posting.google.c om...
> Hi everyone,
> I am developing a web app and wanting to store documents (doc, xls,
> pdf, ppt...etc.) within the DB (MSSQL). Is it advisable in general (I
> don't know exactly how big the docs are going to be) to compress the
> files before putting them into the DB? How does this affect Full Text
> Searching? On a wider note what's the attitude of people in terms of
> storing documents in the DB versus on the file system. There seems to
> be a lot of differing opinions. Any links to resources would be most
> appreciated.
> Thanks for your help in advance.
> Jose
|||John,
Thanks a lot for the detailed reply which you gave - it is most
appreciated. In answer to your question, yes I am running SQL Server
2000 (Version Information - Microsoft SQL Server 2000 - 8.00.760
(Intel X86) Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft
Corporation Standard Edition on Windows NT 5.0 (Build 2195: Service
Pack 4)).
To clarify, I meant storing documents as "ZIP files in columns defined
with the IMAGE datatype". Thanks for the URLs regarding the ZIP
IFilter - I will investigate them. Your post was very helpful -
thanks.
Jose
"John Kane" <jt-kane@.comcast.net> wrote in message news:<#qtcv8pIEHA.964@.TK2MSFTNGP10.phx.gbl>...[vbcol=seagreen]
> Jose,
> First of all, can I assume that you are using SQL Server 2000? If so, could
> you post the full output of: SELECT @.@.version -- as this is very help info
> in understanding SQL FTS issues.
> Secondly, what exactly do you mean by "compress[ing] the files before
> putting them into the DB?" Do you mean to store them as ZIP files in columns
> defined with the IMAGE datatype? or are you thinking about placing the FT
> Catalog folder (SQL00060005) & files on a compressed drive. As for the
> latter, I've not done any testing with compressed drive, but Hilary Cotter
> has and from past postings on this subject, he's indicated that the
> performance gains is mimumal. As for the former, you will need to purchase a
> 3rd Party IFilter for the WinZIP ZIP file format and then assuming you are
> using SQL Server 2000, you can store the zip files in an IMAGE datatype and
> define a "file extension" column that will have the value of "zip" and the
> ZIP IFilter will be called by the MSSearch and the mssdmn (Search Filter
> Daemon) processes to FT Index the contents of the zip file that contains MS
> Word documents. You can purchase the ZIP IFilter from either of the
> following two vendors:
> http://www.4-share.com/content/products.htm
> http://www.ifiltershop.com/zipfilter.html
> I've personally have been using the 4-Share ZIP IFilter for over a year and
> find it works very well for me.
> As for "storing documents in the DB versus on the file system", this is very
> much a open and very actively discussed subject, below is one past posting
> I've made on this subject with links included...
> "There are many issues related to storing the files on disk (faster access,
> easy copy/move, etc.) vs. storing the files in the database (transaction
> control, change control, audit of changes, etc) than just efficiency and
> scalability, although, those are important points... There is a ASPFAQ
> website that has a number of references
> (http://www.aspfaq.com/show.asp?id=2149) and links to KB articles (I've not
> checked them all), but one major reason for storing the files in a SQL
> Server table's column defined with an IMAGE datatype, is that in SQL Server
> 2000 you can take advantage of the new Full-Text Search (FTS) feature to FT
> Index the contents of supported file types, primarily MS Office, HTML and
> 3rd party IFilter's like Adobe's PDF files.
> As this is one of those FAQ type questions that have been known to start
> religious wars or at the very least a flame war, and while Sharon didn't ask
> about other application issues that this question often generates as it is
> often an open-ended question, i.e., one that never seems to be answered to
> everyone's satisfactions as it usually "depends" upon the application or
> upon how one defines the word "best"...
> As for the Terra Server, checkout the "about page"
> (http://terraserver-usa.com/about.aspx?n=AboutBody) on the site that
> explains how MS and others did it and yes, they used the IMAGE datatype,
> specifically
> http://terraserver-usa.com/about.asp...utTechDbschema (The Imagery table
> contains the "blob" [image] field where the imagery data is stored.
> Jose, depending upon how many files you have, how frequently they change,
> how large they are, what the app is, etc. you may want to review the Terra
> Server web site and consider the following rule of thumb that they used:
> < 1 million images or big images (> 1MB) put them in the file system.
> Note, you can also use "Text-in-Row" if the files are >7000 bytes on avg.
> For everything in between, either way will work, depending upon if you need
> transactional control over your files. Additionally, if you store the files
> in a TEXT or IMAGE column, you can also store related metadata about that
> file in SQL Server as well for increased searching capabilities. Also, and
> obviously with SQL Server you get built-in support for validating the
> consistency of the database, indices, backup, restore, etc. As for loading
> &/or extracting the files from SQL Server there are now many methods of
> doing this via BCP, BULK INSERT as well as ADO Stream DTS too, if you need
> to transform your files in some manner.
> Hope this helps, as the primary consideration should always be what is best
> for your application...
> Regards,
> John
>
> "Jose Perez" <jlpv@.totalise.co.uk> wrote in message
> news:3724a9d9.0404141212.480e1630@.posting.google.c om...

Sunday, March 11, 2012

Complicated join question.

Hi there.

I'm running Microsoft Business Solutions GP 8 backed by SQL Server 2000. I need to write a little C#/.NET 2.0 app to go "behind the scenes" to the SQL server in order to fetch and alter some data.

Unfortunately, the tables that GP 8 has created seem strange to me; I've encountered an issue with a SELECT clause featuring two INNER JOINs.

I need to select columns from three different tables. Unfortunately, the key structure of these tables is strange at best. You may view the structure of the three tables from the following URL.

http://pastebin.com/732226

My SQL query is as follows.

SELECT IV30400.DOCNUMBR, IV30300.DOCDATE, IV30200.GLPOSTDT, IV30400.SERLTNUM, IV30400.ITEMNMBR, IV30400.SERLTQTY

FROM IV30400

INNER JOIN IV30300 ON IV30300.DOCNUMBR = IV30400.DOCNUMBR

INNER JOIN IV30200 ON IV30200.DOCNUMBR = IV30300.DOCNUMBR

The key I am joining on is DOCNUMBR. The end result is that I get multiple copies of the same joint row in my result set. I only want one copy of each joint row.

Curiously, the DOCNUMBR key column does not contain unique values. In several rows (in each of the tables, mind you), the value in the DOCNUMBR column is identical. I don't know of this is the cause of my problem.

If anyone can help me sort out this thorny problem I would greatly appreciate it.

Thank you,

--JT

Curiously, the DOCNUMBR key column does not contain unique values. In several rows (in each of the tables, mind you), the value in the DOCNUMBR column is identical. I don't know of this is the cause of my problem.

I have seen programs like this and it is horrifying at best to work with the data (and this is their goal by making the table names so darn user friendly. I couldn't open your pictures, so you might just want to script them out.

Are there any queries in the program that give you somehting close to what you want? I used canned reports from the program I was working with to figure out the really hairy schema using Profiler (the greatest tool in the SQL Server toolbox.

Also, look to see if there is any table with docnumbr unique, of see if there is some other uniqueness criteria you can use.

|||

GROUP BY?

SELECT IV30400.DOCNUMBR, IV30300.DOCDATE, IV30200.GLPOSTDT, IV30400.SERLTNUM, IV30400.ITEMNMBR, IV30400.SERLTQTY

FROM IV30400

INNER JOIN IV30300 ON IV30300.DOCNUMBR = IV30400.DOCNUMBR

INNER JOIN IV30200 ON IV30200.DOCNUMBR = IV30300.DOCNUMBR

Group By IV30400.DOCNUMBR, IV30300.DOCDATE, IV30200.GLPOSTDT, IV30400.SERLTNUM, IV30400.ITEMNMBR, IV30400.SERLTQTY

Does that help at all?

Adamus

|||

Hi Adamus,

That indeed removed the duplicate result rows. I'm not sure WHY it works: I'm guessing that it's because the GROUP BY clause doesn't contain any sorting criteria, and thus it drops the duplicate rows altogether. Thank you for your suggestion!

Now I wonder why the tables are organized in this fashion. It almost seems counter-productive. Oh well.

Thanks again,

--JT

|||

Sounds like sloppy table design. Must've been crunched for time.

Adamus

Sunday, February 19, 2012

Compiling ideas about security

Dear gurus,
We have got front-end and back-end app write in VB6 which at the beginning
retrieve information of paramount importance through XP registry, info such
as: login, password, strategic folders and so on. Well, I have been thinking
in change this and maybe storing that information in Sql tables help us to
display better our hindrances as well as holes security.
-Storing these data in Sql tables and encrypting the data there (how?)
-Storing these data in XML ??
Any help will be greatly welcomed.
Thanks in advance,
EnricHi Enric,
I see a small problem with storing your login info in SQL tables.
What would happen if your SQL password were to change? How would the app
retrieve the changed password if it can't login to the DB to begin with? :)
In terms of storing it in XML files or any config files for that matter,
what we did was we wrote a custom encryption/decryption function to handle
the read and write. To be more specific, we implemented the triple-DES
algorithm.
Hope this helps.
EK
"Enric" wrote:

> Dear gurus,
> We have got front-end and back-end app write in VB6 which at the beginning
> retrieve information of paramount importance through XP registry, info suc
h
> as: login, password, strategic folders and so on. Well, I have been thinki
ng
> in change this and maybe storing that information in Sql tables help us to
> display better our hindrances as well as holes security.
> -Storing these data in Sql tables and encrypting the data there (how?)
> -Storing these data in XML ??
> Any help will be greatly welcomed.
> Thanks in advance,
> Enric
>|||Why not use Windows Domain level security rather than create your own
security layer?
Password recovery mechanisms are inherent security weaknesses, so don't
store the password at all. Instead, store a secure hash of the password with
salt. The MS Crypto API provides the tools to do this.
David Portas
SQL Server MVP
--|||It sounds like you are basically wanting to query sensitive information from
it's designated location (Active Directory) and save it off where it is more
accessable. But accessable to whom? There are probably developers in your IT
department with admin logins to SQL Server. Unless this is part of some
disaster recovery plan, and the data is placed offsite in a safe deposit
box, I do not see the need for it.
"Enric" <Enric@.discussions.microsoft.com> wrote in message
news:B8CB31DE-F58E-4DB8-BE68-586E387DF217@.microsoft.com...
> Dear gurus,
> We have got front-end and back-end app write in VB6 which at the beginning
> retrieve information of paramount importance through XP registry, info
such
> as: login, password, strategic folders and so on. Well, I have been
thinking
> in change this and maybe storing that information in Sql tables help us to
> display better our hindrances as well as holes security.
> -Storing these data in Sql tables and encrypting the data there (how?)
> -Storing these data in XML ?
> Any help will be greatly welcomed.
> Thanks in advance,
> Enric
>