iOS 11 / Xcode issue - Implicit declaration of function 'sqlite3_key' is invalid in C99

Thanks, this works for

Xcode 9.4.1 (9F2000)
CocoaPods 1.5.3
FMDB 2.7.2
SQLCipher 3.4.2

1 Like

This is not working for me
I use sqlcipher 3.4.2 and cocopods 1.5.3 and xcode is 10

I dont use FMDB but still am facing this problem
Any help please.

Hi @deepthi_nagaraja

Can you update to the latest version of SQLCipher? We have updated our Cocoapods spec to improve the header search paths. If it is still not working for you once you have updated, please post additional information about the error you are receiving.

1 Like

Hello thanks for getting back to me
I would like to get more help from you
Initially we were using the headers as #import <sqlite3.h> …later we changed to #import <sqlcipher/sqlite3.h>
After which it started throwing “file is not a database” error
So we reverted back to #import <sqlite3.h>…now it’s throwing c99 error…we change to 4.0 but we still see error on importing

@deepthi_nagaraja

Initially we were using the headers as #import <sqlite3.h> …later we changed to #import<sqlcipher/sqlite3.h>

As @developernotes mentioned the best thing to do is to use the latest version of SQLCipher which has the pod spec that automatically sets up the header search paths for you correctly. This will allow your #import <sqlite3.h> statement to choose the correct SQLCipher sqlite3.h and not the built in system one (which doesn’t contain the sqlite3_key definitions).

After which it started throwing “file is not a database” error

This error usually indicates that you’re attempting to open an encrypted database with the incorrect/no key or open an unencrypted database with a key. Are you creating a new database? If you’re attempting to encrypt an existing non-encrypted database you’ll want to use the sqlcipher_export() convenience function.

So we reverted back to #import <sqlite3.h>…now it’s throwing c99 error

This is almost definitely because Xcode is choosing the system version of sqlite3.h which doesn’t include the sqlite3_key as noted earlier.

we change to 4.0 but we still see error on importing

Which error is this? Did you execute pod install again after updating your Podfile?

If none of this points you in the right direction, it may be helpful to create a test project with the steps you’re using for integration, upload it to GitHub and post a link.

Hi @mmoore
Thanks for the reply
After changing to 4.0 version, now i can see the path in “Header Search Path”
But it just throws me with “include of non-modular header inside framework module” I made “Allow Non-modular Includes in framework modules” , it started working
but its still throwing status 26 Error"File is not a database"

We are not creating a new database
This generally throws error when the app gets updated from one version to another (The change we have is the way we are importing the header from #import <sqlite3.h> to #import <Sqlcipher/sqlite3.h> ) After which when we try to access the database it throws error saying file is not a database error.
we use sqlite3_key.

And also for the password, I use DB Browser and check the path and password,its accurate…I could open without any difficulty

Can you please help, its causing the serious issue.

and if i try doing sqlite_export ," its throwing no such function error"

@deepthi_nagaraja the error you’re seeing is likely due to version incompatibility if you are using an existing database. See this reference:

But I faced issues even before updating the sqlcipher version to 4…
I was using sqlcipher 3.x …
Just after Changing the header ,it stopped considering the older files.
To add the point, I use pragma_cipher_migrate soon after sqlite3_key

Any help appreciated…we are in need of it

Hello @deepthi_nagaraja

It sounds as if your organization may rely on SQLCipher. You might consider purchasing a commercial license to the software, which will include access to private, prioritized support.

How will purchased version help us?

@deepthi_nagaraja - Commercial Edition uses a different integration approach which offers greater control over how the SQLCipher software is linked with your software. You can read about it here:

https://www.zetetic.net/sqlcipher/sqlcipher-binaries-ios-and-osx/

This would allow you to setup whatever paths you need, without having CocoaPods settings override. It’s also faster since everything is pre-built.

If you’d like to try this approach, feel free to fill out a trial request here:

https://www.zetetic.net/sqlcipher/trial/

@sjlombardo
I ran with #import <sqlite3.h> with all set like header search path etc etc…but could not get rid if this error…“File is not a database”
How do you assure that this wont happen on purchased version ?

@deepthi_nagaraja Again, the best way to try this would be to request a trial:

https://www.zetetic.net/sqlcipher/trial/

You can try the Commercial Edition package for free for 15 days.

ok thanks you , I will try these and update

Hey…can you tell me one more thing…what are the chances that sqlcipher’s sqlite3 will get overridden and uses other references of sqlite3 (may be xcode’s sqlite3)…
When I run pragma cipher version…it throws saying it’s not sqlcipher …but I could compile stuff successfully.

We have followed the link to integrate trial version of sqlcipher… but still ninfave ossuy with sqlite3_key with ,c99 error…
We have multiple sdk support code …so can you help us out

@deepthi_nagaraja If PRAGMA cipher_version returns null and does not report a version then you have not linked SQLCipher. That means your application is using the standard SQLite. This is almost 100% guaranteed to be a project configuration problem.

What might be reasons for this ?
it was all good before …The change we made was using use_frameworks and changing the import path …How can that affect our configuration
In one of the site you have mentioned something like this " One such example is when using CocoaPods, or some other sub-project, that declares a dependency on the sqlite3 library. In that case, adding a pod to a project could “silently” modify the project settings in such a way that SQLCipher would not be properly linked. This might not be immediately apparent to a developer unless they are looking closely at the dependencies and testing."…So what might be other causes that i can think of

I can’t speculate on what the problem can be. I’d suggest exhaustively reviewing the project and all dependencies for any linking against the standard sqlite library. If that does not work, I’d setup a simple standalone application and then start adding in dependencies to see if you can find out what is causing it to break.