I am using Apex4.0.2.
Does anyone know what kind of query Shared Components / Static Files uses?
It is certainly a view on WWV_FLOW_FILE_OBJECTS$.
But looking at view APEX_WORKSPACE_FILES not all
(workspace_id - workspace_name - application_id - application_name - mime_type)
appear in Shared Components / Static Files
I am using Ant to assemble and upload static files to oracle because it's quicker than using the interface. The result in WWV_FLOW_FILE_OBJECTS$ is usable but doesn't appear in the interface under Shared Components / Static Files which would be good to have.
Is there an auxilliary table involved?
Alastair
My suggestion is don't do this. Messing around with undocumented, internal storage is probably going to end in heartbreak. Do you never intend to upgrade your Apex instance? Who knows if this will keep working once you do that. I'm assuming this is "too slow" as you move an application from one instance to another?
My first suggestion is upgrade to Apex 5.x. When you do an application export, the application files (not the workspace files) go with the application and are installed when you install the application. Which, by the way, you can do from sqlplus in a script.
If you're stuck with Apex 4.x for the moment, what I did was to add the files to the application, then create an install script (I forget what section of Apex you do that in) that installs the files. This is a little annoying, because every time you change the file, you have to delete the script and recreate it.
Related
I was having some trouble bulk-loading records to go faster than what cursor.executemany would allow. I hoped the bulk operations documented with regular MonetDB here might work, so I tried an export as a test. e.g. cursor.execute("COPY SELECT * FROM foo INTO '/file/path.csv'"). This doesn't raise an error unless the file already exists, but the resulting file is always 0 bytes. I tried the same with file STDOUT and it prints nothing.
Are these COPY commands meant to work on the embedded version?
Note: This is my first use of anything related to MonetDB. As a fan of SQLite and a not-super-impressed user of Amazon Redshift, this seemed like a neat project. Not sure if MonetDB/e is the same as MonetDBLite - the former seems more active lately?
Exporting data through a COPY INTO command should be possible in MonetDB/e, yes.
However, this feature is not working currently. I was able to reproduce your problem, i.e. the COPY INTO creates the file where the data should be exported to, but doesn't write the data. This does not happen with regular MonetDB.
Our team is notified of this issue, and we're looking into it. Thanks for the heads up!
PS: Regarding your doubt about MonetDB/e vs MonetDBLite: our team no long develops and maintains MonetDBLite. Both are embedded databases that use MonetDB as the core engine, but MonetDBLite is deprecated. After having learnt some do's and don'ts with MonetDBLite, our team is developing our next generation of embedded databases.
So for your embedded database needs, you should follow what's coming out of our MonetDB/e projects.
I've created a test for it at: https://github.com/MonetDBSolutions/monetdbe-examples/blob/CI/C/copy_into.c
Also filed a bug report over on GitHub: https://github.com/MonetDB/MonetDB/issues/7058
We're currently looking into this issue.
So I have this source code of a software which is probably developed in oracle.
Can anybody tell me how can I turn this into an actual software?
I am a newbie.
Screenshot
Those are Oracle Forms (.fmx) and Reports (.rep) executables, as well as a Menu module (.mmx). In order to run them, you'd first have to know which Oracle Developer Suite version it is; might be anything from at least 4.5 over 6i/9i/10g or even later; who knows, they all share same extensions.
Forms up to 6i are client-server; later versions are web-based so you'd have to install IAS (Internet Application Server) or WebLogic server; none of those installations is trivial so - if you can't even recognize what you have, you'd rather not do that on your own - consider hiring a consultant.
Once you manage to set it up, you'd run the .mmx file as it looks as the menu for that application.
However, it's not that simple - in order to run such an application, you have to establish connection to the database, i.e. a schema that contains tables used by this application. There's the "Database" folder - maybe it contains some more useful info, perhaps export file (.dmp), maybe even .dbf files ... can't tell just by looking at the icon.
It might be enough if all tables are owned by the same user; otherwise, application might fail because of missing dependencies.
Finally, I think that your best option is to find out someone who actually knows what it is, which development software was used to create those forms & reports and then see if something can be done. It would be simpler/easier if you had .fmb and .rdf (or .jsp) files instead of executables as you could edit them.
We are working on Joomla3.9 project, have different environments and are using git as vcs. So every developer works on is own branch. It would be nice to have a database compare function like in TYPO3 or Contao (see the database differences after updating the project and apply the database changes just by one click). Or like the laravel migration system.
Any developer should easily update his own lokal database after database changes where made due an extension update via backend or by another developer. And of course the staging or live system must be updated easily too. We don't want to execute sql-scripts with the changes in phpMyAdmin.
We have tried https://dbv.vizuina.com/ . This is not the 100% solution. Like there is no cli support to start the migration process by an update script on the server.
Does anyone have a solution or knows an extension that can solve this problem? Or can this be handled with core Joomla functions (maybe with a little adjustment)?
So far, I've seen three possibilities to execute modifications to one ore many extension tables
1: Use the extension - revision control in the schema table. So add a new sql-file with an increased version number compared to the version number in the schema-table for this extension. Increase also the version in the manifest.xml and zip the extension again.
Reinstall the extension via extension->manage->install. So the new sql-file with the increased version number will be executed.
2: like the point above, but install the extension via joomla update mechanism (update server).
3.: create a new sql-file in sql/folder of the extension. No version name is needed for the new file, just update.sql oder another filename. Execute this script in script.php in update()-method, after the extension is installed (in this case it's an update) again.
The third possibility might be interesting. It should be possible to trigger the update()-method with a cli command / function, so that the method can be triggered via a script on the server.
But how can I get the info, which update-scripts have already been executed? Let's say I have 3 update files in sql-folder. update-1.sql, update-2.sql and update-3.sql.
update-1.sql has already been executed. So I don't want to execute this sql-file again - only the other two.
The schema-table is only used with the first two options. Do I have the info somewhere or must I manage the infos which update-scripts have been executed myself?
The answer related to versioning database for extensions depends on whether these extensions are tightly coupled to the application or need to be reusable to other applications also.
The latter case normally means that each extension accesses its own custom tables, in which case you should keep separate versioning for the database than for the extensions.
App version history can be kept in a db_version table. Then an insert statement is added at the end of each update script (adding an incremental version number). e.g.
insert into db_version(version,author,description) values(003,'Verna.Collins', 'removing obsolete column');
Provided that you need to apply data migration on extensions also, you need to maintain a db_version_extensions table which keeps version history for each of the extensions separately. e.g.
'001' 'extension1','Mandy.Aguilar','initial version'
'002' 'extension1','Mandy.Aguilar','adding extra column'
'001' 'extension2','Edna.Potter','initial version'
'002' 'extension2','Elvira.Townsend','dropping unused table'
..etc
Each extension zip should keep initial creation script and all sql-update files(which should normally not interfere with the rest of the app tables).
After pull it will be relatively easy to execute all the scripts with filename version greater than the last version number written in the database. This should be done for the app and for each extension separately.
Now if the extensions are tightly coupled to the app, it means that they might be using/updating tables of the app. For extensions of this type, you can add the updates as part of the application updates. These extensions could even be developed at the same repo, and be kept as directories instead of zip files.
Not sure if joomla supports any tools for automating the process of performing incremental db updates, but a nice tool is flyway, with ports for command-line, maven and graddle. See: how does flyway work
I'm working on an APEX WORKSPACE with many legacy applications. In my shared components I have a lot of workspace images that I can not tell which applications are using or not. There is a way to search the apex or the database for components or codes using these images? The only way to do this I have found so far is to search application by application but this will take forever.
Thanks.
As romeuBraga suggested, you can use the Designer's search function. If you have exports of all your applications in source code control (you do, don't you?), you can check them out to a directory and grep through them for each images filename.
I'm developing a ADF Fusion Web Application in JDeveloper 12. After the creation of the project I took a look at the file system and a bunch of directories were created.
Can anyone tell me what the .adf folder is good for? I can't find anything about it in the Oracle Docs. I'm developing with git and I'd like to know if I have to version this directory, too.
Thanks in advance!
Inside the above mentioned folder can be found two files: adf-config.xml and connections.xml. For an overview of their usage you can take a look at these links:
Oracle ADF XML File Appendix and Web Center. In both of them it states that there are stored application-level setting during design time, which can be used later during the deployment process (it seems quite important though :) ). So, even if you delete that folder it should be recreated if you make any changes and redeploy the application, BUT, if it is there it means it should be there (typical Oracle politics ;) ). So even if you are really in need of their settings (such as modify connection details to point to production server instances) it should be versioned as well.
I'm using svn, and it does version it automatically.
Hope this helps.
ADF creates several files and folders that are needed by the project.
It creates them when the project uses a functionality that needs those files.
In .adf/META-INF/ you can find adf-config.xml & connections.xml which are Application Level Settings.
But for example src/META-INF/jazn-data.xml doesn't exist until you enable Security on your application. This file is also needed and should be on SVN/Git.
ADF also creates some temporary files and folders that shouldn't be on Git/SVN.
Like: .data/.
Depending on what technologies you use from the ADF stack (ADF BC, ADF Model, ADF Controller, ADF Faces), you should understand what files and folders are created.
If you have searched for .adf/ in the official Documentation you would have found your answers.
ADF by default creates .adf and .data file, .adf file you can say is for holding various info related to your workspace in IDE i.e the connections that its having with Database, META-INF info used for customization purpose.
& .data support your MDS functionality.
we can always delete it but our Jdev will create it automatically, whenever we rebuild our application.