I need to run a report with a user that uses objets from a diferent schema. I have used the before_parameter_form trigger to call a database procedure that executes an "alter session set current_schema = XXX" and with simple reports with only some querys in the data model the schema change works fine.
The problem comes when I try to run a report with some program units, for example a formula column that defines a cursor on a table from that schema. This kind of report fails during the first execution, throwing a "REP-1247: Report contains uncompiled PL/SQL" exception. After that first fail, the report works just fine while the database session that the reports server opens is alive.
My guess is that reports server first compiles the report, and if we make use of an object from another schema, it fails, but somehow also executes the before_parameter_form trigger so the default schema gets changed for that session, so afterwards the report keeps working just fine.
Is there any way of forcing the default_schema change before the report compilation?
Using synonyms is not an option, that's the main goal of all those changes.
Thanks!
Related
We have a oracle 12.1 Prod database. One of the packages in the database become invalid abruptly and all the sessions have the state of that package has been invalidated. We are sure that there was no manual actions (Deployment, DDL, Compile etc.. ) performed on the database. Is there any other way that package can become invalid automatically?
This package is directly referencing 3 remote database tables using DB link.
If any dependency undergoes a DDL operation, it will invalidate stored PL/SQL programs that depend on it. It could be a table, a synonym, a view, another PL/SQL routine, etc.. I suggest you look at dba_dependencies to see what the dependencies are for your package, then look at dba_objects for every one of those objects to see what has a recent last_ddl_time value. Don't forget the remote objects on the other side of that database link. When you find it, you are well on your way to finding the root cause. If you can't figure out what DDL is hitting that object, enable DDL auditing so you can capture the event the next time it happens.
If you find that the offending object cannot avoid undergoing DDL for some reason, then you may need to consider breaking the dependency on it by embedding your reference to it inside an EXECUTE IMMEDIATE.
I am working on an APEX application and am faced with an issue in which data present in the database is not read by the application. Rather, the application reads some of fields from the database and not the rest without throwing any error message.
This small application has a main page that contains tombstone information about work projects we are engaged in and is represented by approximately 30 Oracle items of type ‘Database column' that are the fields of the main project overview table. This main page also has several interactive reports that allow the users to manipulate data from other related tables like project costs, project deliverables, project recommendations, etc. While the functionality to create/update/delete from these related tables works perfectly, I am still unable make the same functionality work for the main table and am unable to figure out why as Oracle is not giving me an error message. The changes I submit in the application clearly hit the database as I can see the record updated in the Oracle Object Browser or by querying in SQL commands. I have visually depicted the situation below and thank you in advance for any assistance.
Open project number ‘1982’ and populate with dummy data and ‘save’.
Entered data appears in the main table correctly
Open record project number 1982 and observe that only some of the fields are
shown in the application even though the fields are clearly populated accurately in the underlying table.
I'm seeing flyway seemingly skip migration "V.*" scripts and fail on a later script. Script V1 creates a table, then script V2 alters it. Except that no table gets created, the database is a fresh DB2 instance then it legitimately complains when an alter is attempted.
I have a related question still open, but it would be helpful to get Spring-Boot/Flyway to log the specific SQL that was tried. Not looking for a log of the SQL migration, but the exact SQL in the migration that was attempted.
I tried adding -Dlogging.level.flyway.core.dbsupport.SqlScript=DEBUG but didn't see any change.
I am taking an existing SQL Server 2016 SSIS package and trying to add an Execute SQL Task. I'm suspicious that the task itself isn't the problem, but just in case, I'll explain it.
It is a simple task to query the count in a table, using an existing OLE connection. I create a user variable, set the ResultSet to Single Row, and put in my statement: "SELECT COUNT(fld) FROM MY_TABLE" It shows no errors, but when I try to execute it, I get the error in the title. I can change it to a BEGIN SELECT COUNT(fld) FROM MY_TABLE; END; or add a GO on the 2nd line - it makes no difference. I can set the ResultSet to None, and it makes no difference. I can create a new OLE Connection and use that, and it makes no difference.
I'm pretty sure it has to do with the Oracle driver, because nothing in the paragraph above makes any sense. I can test the connection and it works, however, and when I use the existing connection, it is parameterized for the project.
So what next? Reinstall the Oracle drivers? Or is there anything less drastic?
I started a new project, make a new OLE connection, a new Execute SQL task, and call an Oracle procedure. It works just fine. It's just trying to edit an existing project that doesn't work. Sometimes.
Oh, I'm also using Visual Studio 2019.
In my project, current approach is to create database if not already exists using CreateDatabaseIfNotExists and doing seeding initial data from that Intializer as well. I also added Code First Migration support after upgrade to Entity 4.4, so that in the future when we change the modle/database structure we can update client side database without drop their exist database.
However it didn't seems to working well, for example, I am now stuck on design time where forms wouldn't load and the error message is something like The model backing the 'myEntities' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269).. But the model and database is indeed the updated version, just seems Migration didn't recognize the database generated by CreateDatabaseIfNotExists, but at the same time all seems working well at run time.
Also after that I noticed that if I let CreateDatabaseIfNotExists initialize a database, Add-migration afterwards will fail and complain that pending migration and ask me to do a update-database. When I try to do a the update-database, it will fail as well because the migration path seems assume the database is in initial setup state and will trying to running all the migration scripts while none should be run as the database generated by CreateDatabaseIfNotExists is indeed sync with current model and should not be migrated at all.
I discovered that there is a MigrationHistory table in System Tables, that table will always save the database initialize history regardless of whether the initializer is CreateDatabaseIfNotExists or MigrateDatabaseToLatestVersion. The difference is that if database is initialized by CreateDatabaseIfNotExists1, everytime the database initialized, the migriationId for that initialize record will be different, butMigrateDatabaseToLatestVersion` will always save same set of migrationId for each of the Migration steps. I guess that is how Entity Framework 5.0 works.
So in the end, I give up and rewrite my DB Access code to seeding the initial database data
in other part of my code rather than the CreateDatabaseIfNotExists or MigrationsConfiguration` class because either suit my need.