Hi Fred,
Well done. These records are indeed a little different. Both forms store
real files because there are lots of non-null attachments in the Report form’s
Bxxx table. Just those extra records in Report Definition are handled like
this.
I thought I standardized all my tools with the same trace args (I did) but I
forgot that I had to set the server option, so my query tool did not prove that
I suspected a GET filter after dumping the Report Definitions, and indeed, the
records in Q have their attachment field value is filled in by a GET filter:
Report:GetReportDefinition Enabled 0500 Get; ARSERVER
Action R 2016/12/28 11:28
Qual: (('Report Attachment Field' = $NULL$) AND ('Report Type' = "Web"))
Actn: 1 of 1: Set Fields: Num fields: 2 Server: @; Schema: Report
Definition
Qual: ('Report Definition GUID' = $Instance ID$)
Fld 1 of 2: 2010015 Report
Parameters = $2010015-Report Parameters$
Fld 2 of 2: 2000012 Report Attachment
Field = $2010012-Report Definition File$
And also interestingly, this filter:
Report:Set Report Definition`! Enabled 0500 Set; ARSERVER
Action R 2016/12/28 11:28
Qual: ((('Instance ID' != $NULL$) AND ('Report Type' = "Web")) AND
('TR.Report Attachment Field' != $NULL$))
Actn: 1 of 2: Push Fields: Num fields: 2 Server: @; schema: Report
Definition
Qual: ('Report Definition GUID' = $Instance ID$)
2010012 Report
Definition File = $2000012-Report Attachment Field$
179 Report
Definition GUID = $179-Instance ID$
Actn: 2 of 2: Set Fields: Num fields: 1
Fld 1 of 1: 2000012 Report Attachment
Field = Value: $NULL$
So, when an attachment is filled in by a GET filter, it gets this value of a
buffer. Attachment rules are not broken – per se.
The Q becomes: what to do about it. If I back up that table to the file system
and then restore it, or, the Report will have a real attachment value, as
opposed to the one retrieved by the GET filter.
The fix I put in is to simply accept that attachment value on retrieval. I
suppose I could simply ignore this buffer or flag it as a “buffer on retrieval”
(ie through a get filter) and assign null to the value but there would be lots
of instances when a non-NULL value would be useful. Just not backup and
restore. An example for non-null would be when you are copying from Report to
another form or even ServiceNow.
I suppose I’ll have to let the script writer decide what to do.
Hmmmm.
Ben Chernys
From: ARSList <[email protected]> On Behalf Of Grooms, Frederick W
via ARSList
Sent: October-10-18 1:47 PM
To: ARSList <[email protected]>
Cc: Grooms, Frederick W <[email protected]>
Subject: Re: [E] Re: Strange goings on with Attachments in form Report - 9.1.02
(& most probably prior)
Report may be a little different as there is a form "Report Definition" that
actually stores the definition attachment for a report
Fred
On Fri, Oct 5, 2018 at 10:49 AM Jason Miller <[email protected]
<mailto:[email protected]> > wrote:
With it described like that, it sounds like some kind of plugin at work.
Jason
On Fri, Oct 5, 2018 at 8:22 AM LJ LongWing <[email protected]
<mailto:[email protected]> > wrote:
So, you have a record that can get the attachment no problem, but when you look
at the DB there is no B or BC entry for the attachment?....if this is true then
the only way that can possibly be delivered is through the Remedy server,
meaning it's not stored in the db at all, it's stored in the Remedy binaries
and delivered as if it existed in the db.
On Thu, Oct 4, 2018 at 5:56 PM Ben Chernys <[email protected]
<mailto:[email protected]> > wrote:
Hi LJ,
The attachment field has both a name and contents. The GUI can save it no
problem (as can Meta-Update now).
Both the name and contents are delivered with GetEntry. GetBLOB returns no
entry in database. There is no record in the B or BC table…
> SthMqry -q select * from B140C2000012 where entryid = '000000000000842'
173747.521 i ArQryGet returns 0 records for select * from B140C2000012 where
entryid = '000000000000842'
> SthMsch Report | grep Attach
2000012 Report Attachment Field(Report Definition File) Attach Max: 0
As for no way – of course there’s a way. It’s called code. There may be
special code for this table. I have not seen this before in any other table
and have saved many attachments from many different tables. Meta-Archive
generates HTML with links to the attachments, so it’s been tested on ALL the
ITSM modules. The Report table has not been part of the default Archive
configs.
Same results with “driver”.
I highlighted the file name below in red.
Cheers
Ben Chernys
www.softwaretoolhouse.com
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.softwaretoolhouse.com&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IuUzZpoH4G8vKkBa7TmXnNHc2-87dHrFn9R25Pv__1k&m=hbXEf8PAjVfpUCDRNEzd4yhhQ1U7Ftr3vAy6QJUN3Os&s=b5vSPqwhTMpAFtmL7J2oVtBZU9k8w6jzfZavCz9btHU&e=>
From: ARSList <[email protected] <mailto:[email protected]>
> On Behalf Of LJ LongWing
Sent: October-04-18 3:40 PM
To: [email protected] <mailto:[email protected]>
Subject: Re: Strange goings on with Attachments in form Report - 9.1.02 (& most
probably prior)
For each Remedy form there is a T, H, and B tables
T - Data
H - Status History
B - Binary (Attachments)
B table is going to have a column for each attachment field, one each for the
file name, original file size, compressed file size.
For each attachment field there will be an additional table...if your table is
123 and your field id is 543 then your BC table would be
B123C543
the BC table is the table that contains the actual attachment...
So the B table contains the metadata regarding each of the attachments, the BC
table contains the ACTUAL attachment....
so, you are saying that there is no B entry, but is there a BC?....without the
BC the Remedy server would have no way of giving you the contents of the file,
without the B it has no way of telling you the name of the file...
On Thu, Oct 4, 2018 at 2:50 PM Ben Chernys <[email protected]
<mailto:[email protected]> > wrote:
Hi LJ,
Correct. The same will be on your system (if you have ITSM and perhaps if you
have a whack of languages).
The GUI handles it OK (as do I now).
What’s a BC table?
> SthMqry -q select * from BC140 where c1 = '000000000000842'
144304.453 E ARGetListSQL returned an error 2. Status messages: 1
144304.453 E ARGetListSQL ==> 2, 552, The SQL database operation failed.
ORA-00942: table or view does not exist
/Ben
From: ARSList <[email protected] <mailto:[email protected]>
> On Behalf Of LJ LongWing
Sent: October-04-18 2:36 PM
To: [email protected]
Subject: Re: Strange goings on with Attachments in form Report - 9.1.02 (& most
probably prior)
So, you are saying that you have a record in a table (Report) that's reporting
that it has an attachment in an attachment field, but when you go look at the B
table it's not showing there?...what about if you look in the BC table? Is the
record there?
On Thu, Oct 4, 2018 at 1:27 PM Ben Chernys <[email protected]
<mailto:[email protected]> > wrote:
Hi Folks,
I discovered something curious about attachment fields. I've never had an
attachment field which had a value (ie a file) with a non-null location in a
myriad of tables. I got one such from the Report table. A type = buffer.
Locations are used when updating attachment fields - or so I had thought.
No matter, I was using getblob to create the file even if the buffer was
already in memory for another reason (when I had done a getblob to a buffer).
I now simply create the file myself when an attachment field comes in “already
retried” in a buffer, so there are no problems with this.
Presumably, these “special” attachments are identified simply by their non-null
attachment location on retrieval. I would wager that if I update this
attachment field, it would transform this record’s attachment into a normal
value and a record would be created in the Bxxx table. – I shall do that test
shortly.
Check out the Report form, there are a few records there with non-null
attachment fields AND no record in the Bxxx table.
When data is retrieved from those records, the attachment value has a name and
the data in a buffer.
When an update to an attachment field is made, no matter if a buffer or file is
used, a new record is added to the Bxxx table.
How is this attachment different than all the others?
Data from my 9.1.02 system:
04/10/2018 13:10:35
e:\ > SthMry -S Report "'1' = \"000000000000842\""
om 1 matches) in Report
<ArIds returned start>
<Id: 000000000000842 →→ →→→ nullWeb nullCBK:ChargeBack
null802; null2 null>
<ArIds returned end >
<-------------------->000000000000842
Request ID 000000000000842
Submitter BMC Software
Create Date 2003/01/24 13:14:58
Assigned To
Last Modified By AR_ESCALATOR
Modified Date 2015/04/09 15:27:04
Status Active
Short Description →→ →→ →→ →→→
Status History
1043439298♦dev_caga♥♥1482978799♦Action Request Installer Account♥
Assignee Groups 802;
Locale ko
Instance ID AG0050569E2243w0gPSAayxAdASvcH
Assignee Groups_Parent
zFormIdentificationMarkerField
Form Name CBK:ChargeBack
Report Type Web
Report Attachment Field CBK_Adjustment.rptdesign
Report Set Name Adjustment Report
Server %%
Override Query No
Report Name →→ →→→
Designer Version
Lock Override Option Yes
Visible In Console No
zTempInstanceCount
Report Parameters
Base Qualification '179' != $\NULL$
Date Range Field ID
Date Range Report No
Datatag config-fin
Category 1
Category 2
Category 3
> mqry -q select schemaid from arschema where name='Report'
"001"
<-------------------->SQL row: 1
Col 0: 140
> mqry -q select * from B140 where c1 = '000000000000842'
131548.456 i ArQryGet returns 0 records for select * from B140 where c1 =
'000000000000842'
Cheers,
Ben Chernys
Senior Software Architect
Canada / Deutschland
Mobile: +49 171 380 2329 GMT - 7 + [ DST ]
Mobile +1 403 554 0887
Email: <mailto:Ben.Chernys_AT_softwaretoolhouse.com>
Ben.Chernys_AT_softwaretoolhouse.com
Web:
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.softwaretoolhouse.com_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IuUzZpoH4G8vKkBa7TmXnNHc2-87dHrFn9R25Pv__1k&m=hbXEf8PAjVfpUCDRNEzd4yhhQ1U7Ftr3vAy6QJUN3Os&s=akOzESdyY4jnPgdqMsThvXOl8d28JVT6UHAxHNdu8HY&e=>
www.softwaretoolhouse.com
We are a BMC Technology Alliance Partner
Check out Software Tool House's free Diary Editor and our Freebies Section for
ITSM Forms and Fields spreadsheet.
Meta-Update
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.softwaretoolhouse.com_product_SthMupd_index.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IuUzZpoH4G8vKkBa7TmXnNHc2-87dHrFn9R25Pv__1k&m=hbXEf8PAjVfpUCDRNEzd4yhhQ1U7Ftr3vAy6QJUN3Os&s=Az6IBSThdVwsMS8kQZfpc96dxV3Fiy3oiksN4TvDG1k&e=>
, our premium ARS Data tool, lets you automate your imports, migrations, in no
time at all, without programming, without staging forms, without merge
workflow.
Meta-Archive
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.softwaretoolhouse.com_product_SthArch_index.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IuUzZpoH4G8vKkBa7TmXnNHc2-87dHrFn9R25Pv__1k&m=hbXEf8PAjVfpUCDRNEzd4yhhQ1U7Ftr3vAy6QJUN3Os&s=uAiT377gyBIM8vu0G9QT-n-cWce5YGiiFlgm_w_-xDE&e=>
does ITSM Archiving your way: with your forms and your multi-tenant rules,
treating each root request as a complete tree and checking associatuions.
Archive output to different servers, HTML pages with links to attachments or
archive forms.
Meta-Databot
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.softwaretoolhouse.com_product_Databot_index.html&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IuUzZpoH4G8vKkBa7TmXnNHc2-87dHrFn9R25Pv__1k&m=hbXEf8PAjVfpUCDRNEzd4yhhQ1U7Ftr3vAy6QJUN3Os&s=fh-PAdZ__OyhljEourMC-IOpgTy71_4hxU3qiHmvOGs&e=>
is an automated, extensible BMC Data Wizard. It reads a file of data changes
and sports an Undo feature.
Pre ITSM 9.1.04? Clarify? HP? Roll your own? No problem! You can keep your
valuable data!
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.softwaretoolhouse.com_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IuUzZpoH4G8vKkBa7TmXnNHc2-87dHrFn9R25Pv__1k&m=hbXEf8PAjVfpUCDRNEzd4yhhQ1U7Ftr3vAy6QJUN3Os&s=akOzESdyY4jnPgdqMsThvXOl8d28JVT6UHAxHNdu8HY&e=>
http://www.softwaretoolhouse.com/
--
ARSList mailing list
[email protected] <mailto:[email protected]>
https://mailman.rrr.se/cgi/listinfo/arslist
<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rrr.se_cgi_listinfo_arslist&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IuUzZpoH4G8vKkBa7TmXnNHc2-87dHrFn9R25Pv__1k&m=hbXEf8PAjVfpUCDRNEzd4yhhQ1U7Ftr3vAy6QJUN3Os&s=snvaeUqmORmrSWOCznX2Fd5KfvwnPx910Jdrevsac8Q&e=>
--
ARSList mailing list
[email protected] <mailto:[email protected]>
https://mailman.rrr.se/cgi/listinfo/arslist
<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rrr.se_cgi_listinfo_arslist&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IuUzZpoH4G8vKkBa7TmXnNHc2-87dHrFn9R25Pv__1k&m=hbXEf8PAjVfpUCDRNEzd4yhhQ1U7Ftr3vAy6QJUN3Os&s=snvaeUqmORmrSWOCznX2Fd5KfvwnPx910Jdrevsac8Q&e=>
--
ARSList mailing list
[email protected] <mailto:[email protected]>
https://mailman.rrr.se/cgi/listinfo/arslist
<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rrr.se_cgi_listinfo_arslist&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IuUzZpoH4G8vKkBa7TmXnNHc2-87dHrFn9R25Pv__1k&m=hbXEf8PAjVfpUCDRNEzd4yhhQ1U7Ftr3vAy6QJUN3Os&s=snvaeUqmORmrSWOCznX2Fd5KfvwnPx910Jdrevsac8Q&e=>
--
ARSList mailing list
[email protected] <mailto:[email protected]>
https://mailman.rrr.se/cgi/listinfo/arslist
<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rrr.se_cgi_listinfo_arslist&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IuUzZpoH4G8vKkBa7TmXnNHc2-87dHrFn9R25Pv__1k&m=hbXEf8PAjVfpUCDRNEzd4yhhQ1U7Ftr3vAy6QJUN3Os&s=snvaeUqmORmrSWOCznX2Fd5KfvwnPx910Jdrevsac8Q&e=>
--
ARSList mailing list
[email protected] <mailto:[email protected]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rrr.se_cgi_listinfo_arslist
<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rrr.se_cgi_listinfo_arslist&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IuUzZpoH4G8vKkBa7TmXnNHc2-87dHrFn9R25Pv__1k&m=hbXEf8PAjVfpUCDRNEzd4yhhQ1U7Ftr3vAy6QJUN3Os&s=snvaeUqmORmrSWOCznX2Fd5KfvwnPx910Jdrevsac8Q&e=>
&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IuUzZpoH4G8vKkBa7TmXnNHc2-87dHrFn9R25Pv__1k&m=hbXEf8PAjVfpUCDRNEzd4yhhQ1U7Ftr3vAy6QJUN3Os&s=snvaeUqmORmrSWOCznX2Fd5KfvwnPx910Jdrevsac8Q&e=
--
Fred Grooms
Senior Software Engineer | Network Systems - Service Assurance |
<http://www.xo.com/> XO Communications - A Verizon Company |
<http://www.xo.com/> www.xo.com
Verizon Certified SCRUM Master
Office: 972.578.6528 | Fax: 972.516.3556 | E-mail:
[email protected] <mailto:[email protected]>
--
ARSList mailing list
[email protected]
https://mailman.rrr.se/cgi/listinfo/arslist
