I am able to convert a SQLCipher file from 1.1.x to 2.0 (found an example "Convert from a 1.1.x to 2.0 Database with HMAC").
Is there a way to revert a database file to the oldest version (From 2 to 1) ?
Googling I found nothing
Thanks
You could do this via PRAGMA statements, the first must be run before you key the database, the second should occur after keying:
PRAGMA kdf_iter = 4000;
PRAGMA key = 'YourDatabaseKeyHere';
PRAGMA cipher_default_use_hmac = OFF;
This assumes you did not alter any other SQLCipher configuration settings. A recommended alternative to the above scenario would be to upgrade your SQLCipher library to the latest 3.x version and perform a single time database format upgrade via another PRAGMA:
PRAGMA cipher_migrate;
Related
I have a requirement to connect to oracle database for this I am using OCCI as programming language. I would like is there any restriction on which client version can be used for a corresponding database i.e. Database to which I am connecting is at version 10.1.0.4. Now can I used 11 Client?
Oracle client versions are generally backward compatible. Unless the server is too old. As long as it is a version greater then 10 it should be fine.
Have a look at the link below. There is a matrix showing interoperability details between client and server versions.
http://orcl.tistory.com/entry/Oracle-Client-Server-Interoperability-Support
My spec to keep in mind:
Oracle db version: 11.1.0
platform: UNIX AIX 5
Apex Version: 4.0.1.00.03
Problem:
We are trying to created a workspace in APEX based on a schema created in the DB 'MLS'.
once we do that it comes up with the error that the schema is restricted or reserved.
There is a patch in place but it is for the APEX version : 4.0.2. have been searching wherever google could take me and no such luck for this particular version. I have been on the OTN Discussion Forum and I have place a question there as well.
Is it possisble anybody could help me with a known patch or work-around please? Upgrading to version 4.1 - is not possible at this point in time.
Any help would be appreciated,
Melanie
Have you tried unrestricting the schema as described in the documentation?
EXEC APEX_040000.APEX_SITE_ADMIN_PRIVS.UNRESTRICT_SCHEMA(p_schema => 'MLS');
COMMIT;
This would lift the restriction for all workspaces. Alternatively, you could add an exception for a specific workspace:
BEGIN
APEX_040000.APEX_SITE_ADMIN_PRIVS.CREATE_EXCEPTION(p_schema => 'MLS',
p_workspace => 'YOUR_WS');
COMMIT;
END;
The final result was to upgrade to version 4.1. Though it is risky that is what the clients want. My personal solution would have been to patch 4.0.2 and apply the patch that was designed for this version. Thanks for the help!
begin
apex_040200.htmldb_site_admin_privs.unrestrict_schema(p_schema => 'SCOTT');
commit;
end;
On Apex 5 do the following:
-- Check restricted schemas
SELECT * FROM APEX_050000.wwv_flow_restricted_schemas;
-- Unrestrict your schema
EXEC APEX_INSTANCE_ADMIN.UNRESTRICT_SCHEMA('OE');
-- Add your schema to your workspace
EXEC APEX_INSTANCE_ADMIN.ADD_SCHEMA('WORKSPACE', 'OE')
-- Don't forget to commit!
commit;
In our server,we publish a asp.net application,which use the oracle11g as the database.
We just set the connection string in the web.config,it works.
However someone install the oracle8 in the same server since they need them in other client application.
But after that,our web applcation can not work,we get the error:
ora-12154 TNS an not handle the service name
Then I found that the path environment has been changed. The "C:/app/oracle81/bin" is added at first. But even I change the "D:/app/oracle11g/bin" first,it does not work also.
Any idea to make the both work?
You might investigate what drivers are being used within .NET ... Microsoft's deprecated Oracle provider or Oracle's own provider or some kind of ODBC provider sitting on top of several kinds of possible drivers in a DSN. Each might be remedied in a different way.
But it sounds like the Oracle 8 installation has stolen priority over the Oracle 11 installation in some way that is not just the "PATH" environment variable. My guess would be the registry.
In ascending order of inconvenience and effectiveness you could try:
1) Run the Oracle 11 installer and see if it knows about the Oracle 8 home. (Unlikely if it's 8.0). Set it as default or top of the list; exit; then go back and set Oracle 11 as the default/top of the list.
2) Configure the TNS entries in your Oracle 8 home to connect to your Oracle 11 database. Live with the fact you're using a very out of date client.
3) Uninstall and reinstall Oracle 11 to get it to steal back the priority.
By default the .net framework uses the FIRST oracle directory it comes to the in the path statement. There have been some discussions on how to get around this - but your best bet is to run one client per machine.
I am using Delphi 5 version and I want to connect to Oracle Database. I am having TDatabase component.
I don't have any idea about how to connect to database through Delphi. Please provide the steps to connect database. thanks.
The TDatabase component is part of the BDE (Borland Database Engine), which is a deprecated technology, instead try using another alternatives which supports Oracle like ADO or Zeos. For an introduction to ADO check the Embarcadero Docs. Working with ADO Components and if you choose Zeos check the Official documentation.
That's funny, I've just finished (some minutes ago) the port of my Open Source native Oracle access to Delphi 5.
Here are the main features of this unit:
Direct access to the Oracle Call Interface (OCI) client, with no BDE, Midas, DBExpress, nor OleDB or ODBC provider necessary;
Dedicated to work with any version of the Oracle OCI interface, starting from revision 8;
Optimized for the latest features of Oracle 11g (e.g. using native Int64 for retrieving NUMBER fields with no decimal);
Able to work with the Oracle Instant Client for No Setup applications;
Natively Unicode (uses internal UTF-8 encoding), for all version of Delphi, with special handling of each database char-set;
Tried to achieve best performance available from every version of the Oracle client;
Designed to work under any version of Windows, either in 32 or 64 bit architecture;
Late-binding access to column names, using a new dedicated Variant type (similar to Ole Automation runtime properties);
Connections are multi-thread ready with low memory and CPU resource overhead;
Can use connection strings like '//host[:port]/[service_name]', avoiding use of the TNSNAME.ORA file;
Use Rows Array and BLOB fetching, for best performance (ZEOS/ZDBC did not handle this, for instance);
TQuery emulation class, for direct re-use with existing code, in replacement to the BDE;
Handle Prepared Statements - but by default, we rely on OCI-side statement cache, if available;
Native export to JSON methods, which will be the main entry point for our mORMot framework;
Compatible with Delphi 5 up to XE;
Since it doesn't use the DB unit, nor DBExpress or such other technologies, works with any edition of Delphi (even Delphi XE Stater or Delphi 7 Personal);
Open Source, released under a MPL/GPL/LGPL license.
See this web site for more details and feedback.
You have a TQuery like wrapper, to write code just like with the BDE.
Or you can write code as such:
procedure Test(Props: TOleDBConnectionProperties; const aName: RawUTF8);
var I: ISQLDBRows;
begin
I := Props.Execute('select * from Domain.Customers where Name=?',[aName]);
while I.Step do
writeln(I['Name'],' ',I.['FirstName'],' ',I['Address']);
end;
var Props: TOleDBConnectionProperties;
begin
Props := TSQLDBOracleConnectionProperties.Create(
'TnsName','UserName','Password',CODEPAGE_US);
try
Test(Props,'Smith');
finally
Props.Free;
end;
end;
Unfortunately, Delphi 5 do not allow late-binding via a variant, which is allowed with Delphi 6 and up:
procedure Test(Props: TOleDBConnectionProperties; const aName: RawUTF8);
var I: ISQLDBRows;
Customer: Variant;
begin
I := Props.Execute('select * from Domain.Customers where Name=?',[aName],#Customer);
while I.Step do
writeln(Customer.Name,' ',Customer.FirstName,' ',Customer.Address);
end;
If you really want to use the DB components in a RAD approach, take a look at the corresponding page in Torry's page:
ATOM Access To Oracle Magic;
DOCI Components for Direct Oracle Access;
NC OCI8;
Orange Component Set;
Vlad Karpov Native Link to Oracle.
You'll find there some old free components, mostly created at Oracle 8 time (SynDBOracle is optimized for Oracle 11g but will work with earlier versions of Oracle), but which may better suit your need for Oracle connection without the BDE.
Of course, there are also some very good commercial components around, still working with Delphi 5. But you'll have to pay the high price... and should better upgrade to a newer Delphi version, by the way. ;)
If you have the Enterprise version of Delphi 5 you can connecto to Oracle using the BDE and the Oracle SQL Link. That's the fastest way to use Oracle from D5. If you have the Professional version, you can use Oracle using the BDE through ODBC. The Enterprise version also should already have the ADO components, but in my tests then it was an inferior solution to the SQL Links, although if you have to port later to a newer Delphi release it is still supported while the BDE and the SQL Links are not.
The steps to connect are detailed in the help and the manuals.
Hi
We have a third party oracle based application, that ships with precompiled binary(wrapped) packages.
But when I compile them in Oracle SQL Developer (right click -> compile all), they get invalidated.
Is recompiling a safe operation with no side effects?
The major side effect is that if you compile a package which another package is dependant upon you risk invalidating the dependant package for any existing sessions - even if the compile has no errors. This is fine for applications where sessions are short-lived but for applications where sessions are long-lived this is a problem. If you're using connection pools in JDBC the cached sessions will be long lived and likely invalidated. You have to flush the cached sessions to avoid the error.
The error you're looking for is "ORA-04068: existing state of packages has been discarded".
See here for more info.
Specifically with regards to SQL Developer - it does not handle recompilation of wrapped packages well. If you are going to recompile them try another tool like TOAD or PL/SQL Developer or use the "alter package" command in the SQL Plus command line.
Personally, I'd avoid 'Recompile All' (in SQL Developer or TOAD) - especially in any environment where you have open database connections from other users or software.
In most situations you probably just want to recompile Invalid objects.
If you're on Oracle 10 or above, there are two in-built packages that will do this (although they may not be accessible to your role without speaking to your DBA).
UTL_RECOMP.RECOMP_PARALLEL(threads => 4, schema => :schema_owner)
DBMS_UTILITY.COMPILE_SCHEMA(schema => :schema_owner, compile_all => FALSE)
UTL_RECOMP is the new preferred way to do it. DBMS_UTILITY exists on earlier versions of Oracle, but would always compile everything - compile_all is a new optional flag, that lets us tell it to compile only invalid items.
If you are on an earlier version than 10, I'd suggest rolling your own compile invalid procedure - I found it useful to write this as a job that can be submitted via DBMS_JOB and then emails back progress via DBMS_SMTP (DBMS_MAIL in Ora 10).
My job recursively tries to compile INVALID objects where all dependencies are VALID, using the following SQL, until there are no changes between iterations.
SELECT uo.object_name,uo.object_type
FROM user_objects uo
WHERE uo.status = 'INVALID'
MINUS -- objects with invalid children
SELECT uo.object_name,uo.object_type
FROM user_objects uo,
user_objects uo2,
public_dependency pd
WHERE uo.status = 'INVALID'
AND uo.object_id = pd.object_id
AND pd.referenced_object_id = uo2.object_id
AND uo2.status = 'INVALID'
Most third party applications advice you against editing/compiling their objects unless of course their support tells you to do so.
Since you do not know all the dependent objects, I would suggest you contact the third-part application's support team first before modifying their objects. If it is a bundled application, simply recompiling oracle objects may leave dependent applications/services in other tiers invalid.
If your packages get invalid are they actually invalid in the sense that they won't work anymore?
Try to recompile an invalid package body using sqlplus.
SQL>alter package <package name> compile body;
If you get the message "compiled with errors"
SQL>show errors;
This will give some information about the error.
Generally speaking it is fine to recompile wrapped packages. Should not be a problem.