The difference is not in char vs substr vs cast, but in filespace_name vs
node_name:
tsm: LFTSM>select (substr(filespace_name,1,10)) as FS1, char(node_name,10) as
NN1, cast(filespace_name as char(10)) as FS3 from filespaces
FS1 NN1 FS3
-
Well that is odd -
I don't know why 2n+1, but at least I get consistent results:
tsm: LFTSM>select (substr(filespace_name,1,10)) as FS1, char(filespace_name,10)
as FS2, cast(filespace_name as char(10)) as FS3 from filespaces
FS1 FS2 FS3
---
Wanda
> You can also do:
> select substr(filespace_name,1,20) from filespaces
>
> and get only 20 chars back.
Well that's interesting because it makes the problem worse! Using either
CAST or SUBSTR truncate my data to N characters, but CAST gives me a
column width of (N+1) for NODE_NAME and (2N+
You can also do:
select substr(filespace_name,1,20) from filespaces
and get only 20 chars back.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Neil
Schofield
Sent: Wednesday, April 17, 2013 1:09 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-
-Neil Schofield wrote: -
>The fact that only the FILESPACE_NAME column is twice as wide as it
>should be makes me wonder if it's a bug?
It probably has something to do with the possible occurrence of
Unicode characters outside the ASCII character set in filespace
names.
Thomas Denier
Tho
Allen
Thanks for the suggestion. The problem I've got is that the reports are
the sort of ad-hoc SQL scripts that are run by administrators and
operators from the admin client. While using '-comma' does reduce the
column width, it is not appropriate in this scenario.
The fact that only the FILESP
On 04/16/2013 04:25 PM, Neil Schofield wrote:
> I'm in the throes of an upgrade from TSM Server 5.5 to 6.3 and have had a
> bit of a problem re-writing some of our custom SQL scripts. I was wondering
> if anyone can point out what I'm doing wrong.
>
I don't know from "do wrong"; but the way I appr
Neil
Had something similar, again with the filespace_name column
To resolve, i do this:
select char(filespace_name,20), etc
On 16 April 2013 21:25, Neil Schofield
wrote:
> I'm in the throes of an upgrade from TSM Server 5.5 to 6.3 and have had a
> bit of a problem re-writing some of our custom
: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Lee, Gary D.
Sent: Thursday, September 28, 2006 9:41 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Select statements
Why not just do a
Q assoc * *
That will give you every schedule and association.
Gary Lee
Senior System Programmer
Ball State
select domain_name, schedule_name, node_name, substr(char(scheduled_start),
1, 16) as SCHEDULED_START, -
substr(char(actual_start), 1,16) as ACTUAL_START,status, result,
reason -
from events
where LENGTH(domain_name) IS NOT NULL and ( (status = 'Started') or
(status = 'Completed') -
or
But it wont give you the schedule time.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Lee, Gary D.
Sent: Thursday, September 28, 2006 9:41 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Select statements
Why not just do a
Q assoc * *
That will give
Why not just do a
Q assoc * *
That will give you every schedule and association.
Gary Lee
Senior System Programmer
Ball State University
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
LeBlanc, Patricia
Sent: Thursday, September 28, 2006 9:25
On May 25, 2006, at 4:08 PM, Laura Mastandrea wrote:
Where do you get the syntax information for the select statement?
i.e.
substr , etc.
I have a selection of SQL references near the bottom of
http://people.bu.edu/rbs/ADSM.QuickFacts
(seek "SQL:")
where the following URL is most appropriate
Where do you get the syntax information for the select statement? i.e.
substr , etc.
Thank you.
To
ADSM-L@VM.MARIST.EDU
cc
Thanks Leigh,
This worked great !
R
On May 25, 2006, at 9:46 AM, Leigh Reed wrote:
select * from volhistory where type='BACKUPFULL' and
date_time>(current_timestamp-1 day)
You can use 'hour' instead of 'day' to get further granularity
-Original Message-
From: ADSM: Dist Stor Manage
select * from volhistory where type='BACKUPFULL' and
date_time>(current_timestamp-1 day)
You can use 'hour' instead of 'day' to get further granularity
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Roger Silva
Sent: 25 May 2006 17:24
To: ADSM-L@V
On May 25, 2006, at 12:24 PM, Roger Silva wrote:
Thank You Sandeep,
I made changes since some of the fields didn't work for me, but
this is
what I have:
SELECT DATE_TIME AS DATE,TYPE,VOLUME_NAME,LOCATION FROM VOLHISTORY
WHERE TYPE='BACKUPFULL'
But, what I would like to do is pull just the las
Thank You Sandeep,
I made changes since some of the fields didn't work for me, but this is
what I have:
SELECT DATE_TIME AS DATE,TYPE,VOLUME_NAME,LOCATION FROM VOLHISTORY
WHERE TYPE='BACKUPFULL'
But, what I would like to do is pull just the last or most current
BACKUPFULL or BACKUPINCR informat
Hi,
You can use below select statement to view the full db backup details.
SELECT DATE_TIME AS "DATE TIME",TYPE,BACKUP_SERIES,VOLUME_NAME FROM
VOLHISTORY WHERE TYPE='BACKUPFULL'
REPLACE 'BACKUPFULL' WITH 'BACKUPINCR' IF YOU TAKE INCREMENTAL
BACKUP
With Best Regards,
Sandeep Jain
Roger
I recently had to query the summary table for info regarding the
database backups. My requirement was to report how long the database
backups were taking. I found that the following select query sufficed.
select substr(char(end_time-start_time),3,8) as backup_duration from
summary where act
Try this on for size.
select node_name, cast(platform_name as char(16)) as "OS/Name ",
cast(client_os_level as char(10)) as "OS/Level", cast (client_version as
char(1)) || '.' || cast(client_release as char(1)) || '.' || cast
(client_level as char(1)) || '.' || trim(cast(client_sublevel as char(2
Thanks to you all, perfect answer!
-Original Message-
From: Cook, Dwight E [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 12:52 PM
To: [EMAIL PROTECTED]
Subject: Re: Select statements syntax
Way to go Paul !
example run against the occupancy table...
tsm: TSMSRV01
Way to go Paul !
example run against the occupancy table...
tsm: TSMSRV01>select cast((physical_mb) as varchar(10)) || cast((logical_mb)
as varchar(10)) as "My Concat Field" from adsm.occupancy
My Concat Field
--
2521.282505.62
294.10293.42
0.030.03
0.000.00
6.146.1
t: Re: Select statements
It's an SQL thing.
SQL operations occur in a certain order.
When you do a SELECT to query a table, the results you get back are actually
another (temporary) table.
"where" clauses are applied to columns in the original table
"order" clauses are applie
24 matches
Mail list logo