Question: I have a pre-existing sqlite database that is about 5mb in size. I use this code to copy from my assets folder to the packages/databases folder on the device. 

The database copies to the device but the data inside the database has been deleted or is missing. The only table inside is called android\_metadata.

Here is the code:

```
try{
        InputStream myInput = myContext.getAssets().open(DB_NAME);

        // Path to the just created empty db
        String outFileName = DB_PATH + DB_NAME;

        //Open the empty db as the output stream
        OutputStream myOutput = new FileOutputStream(outFileName);

        //transfer bytes from the inputfile to the outputfile
        byte[] buffer = new byte[1024];
        int length;
        while ((length = myInput.read(buffer))>0){
            myOutput.write(buffer, 0, length);
        }

        //Close the streams
        myOutput.flush();
        myOutput.close();
        myInput.close();
        }catch(SQLiteException e){

```

Answer: 
It sounds like you are hitting the Firefox default font policy.

Firefox does not allow cross-domain fonts by default (even with sub-domains). See the following questions for some excellent help in this area:

[@font-face fonts only work on their own domain](https://stackoverflow.com/questions/2892691/font-face-fonts-only-work-on-their-own-domain)

[How to add an Access-Control-Allow-Origin header](https://stackoverflow.com/questions/5008944/how-to-add-an-access-control-allow-origin-header)
One way around the same-origin font policy is to use relative links `(../fonts/font-name.ttf)` or absolute links `(/fonts/font-name.ttf)` to your font files instead of putting the FQDN (Fully Qualified Domain Name) in the `@font-face` src path (`http://www.example.com/fonts/font-name.ttf`).

However, even if you're using flexible file paths to your font files from your stylesheets, if you're serving the CSS form a different domain (or sub-domain) than where it's being requested you'll still be faced with the same origin policy.

Since WordPress theme URLs are generated using the full domain name in the path, this by itself is much of your problem.

For example, if you're viewing this page:

`http://example.com/about`

and the fonts are being served via CSS from:

`http://www.example.com/css/screen.css`

You'll encounter the same origin policy (since the fonts specified in the CSS are being served from a different domain. Remember, sub-domains such as "www" are technically considered a separate domain).

One way around this problem is to configure Apache to [forward all incoming URLs](https://stackoverflow.com/questions/1100343/apache-redirect-from-non-www-to-www) to the domain name that matches your WordPress Site Address.

`example.com -> www.example.com` (or vice versa)

Doing this will ensure all images, stylesheets and fonts are served from the same domain, thus circumventing your problem(s).