Forum

This content is now out of date.

Visit Our Community

Cannot Delete View

Greetings YF Team!

In build 20150123 of YF 7.1, I cannot delete views. I issue the delete command, I am shown a list of reports linked to the view that will also be deleted, and I click OK and I am then taken back to the admin console.

This was not an issue with the December release, so I assume its a problem with the new release. Is that the case?
Hey Justin,

Sorry to see that you are having some issues deleting a view in
the latest release of YF.

Did you upgrade from Dec build?

Can you confirm that this is what you are seeing when you
select the view to delete?


Forum image


When I select 'OK' I am then taken back to the view page and
the view is no longer there. I've tested in the latest build of YF.

Do you receive any type of error message or is the view just
still present??

Please let me know and I'll continue to look at this for you.

Thank you,

Kyle
I see what you are seeing, but when I click OK, the view is not deleted. I still have the same number of views present in the admin console, and when I check, the view is still there.


Yes, I upgraded from December to January
Hi Justin,

I've had a look at the logs, and I'm seeing some DB related issues, which should not be caused by any YF upgrade.

Here is what I'm seeing;

[code]
ERROR (DBAction:doInsert) - Error occured doing insert: java.sql.SQLException: ORA-01654: unable to extend index CEP_ADMIN.XZKEVENT by 1024 in tablespace USERS
[/code]

This is peppered throughout the log and explains why no changes you make in the browser are having an affect.
Seems that the tablespace itself is full, or you don't have hard drive space left for it to increase.

See the following 2 posts for more info on this:
https://community.oracle.com/thread/1120345
http://www.dbforums.com/showthread.php?921581-ORA-01654-unable-to-extend-index

You will need to shutdown Yellowfin when making these DB changes.

Please let me know how you go with this.

Regards,
David

There is probably a limit set in the database during install in the control files that is preventing this.

That said, are there any queries I could run to flush the tables safely? Yellowfin has produced 16 million lines of HUGECLOBs between 2 tables, and my dataset itself is not that large, and does not include any non-VARCHAR2 or NUMBER fields, and the 6 tables in all dont add up to 16 million lines.

This is one of the reasons I was hoping for an ERD and Data Dictionary to be posted for the install.

For the moment, I have added another datafile to my tablespace as a workaround.
Is there anything that can be done to flush all the info that YF is caching in the database? I'm thinking there is some cleanup that hasnt been done that normally takes place , so my DB size just keeps swelling.
Hi Justin,

yes there are steps that can be taken, but first, to ensure that we give you only relevant steps please tell us which are your largest tables and how big they are.

regards,
Dave
2 installs:
DEV_YF_CONFIG (20 users)
REPORTINSTANCEFILTER 10.4 million rows 258MB
REPORTINSTANCE 4.8 million rows 3.11GB
EVENT 1.5 million rows 395MB
EVENTARCHIVE 3.7 million rows 976MB

PROD_YF_CONFIG
5 users
REPORTINSTANCEFILTER 17.9 million rows 534MB
REPORTINSTANCE 7.3 million rows 4.56GB
EVENT 3.7 million rows 1011MB
EVENTARCHIVE 3.8 million rows 980MB
Hi Justin,

the following 2 queries should clear the ReportInstance table (whilst leaving all KPI reports & cached reports intact):

[code]
DELETE FROM ReportInstance
WHERE DocumentId = 0
OR DocumentId IS NULL
OR ReportId not in
(SELECT ReportId FROM ReportHeader WHERE RoleCode = 'KPI')
[/code]

[code]
DELETE FROM ReportInstanceFilter
WHERE InstanceId NOT IN
(SELECT ReportInstanceId FROM ReportInstance )
[/code]

and as for the Event and EventArchive tables, they are only used for audit purposes so you can delete as many rows as you want from them.

Please remember to back up your YF DB before running any back-end queries.

Please read this forum post for information on how to configure the size of the Event table.

regards,
Dave