Support

Are you using it as a portable application, or through the regular desktop installer? Does your Windows user name contain any non-ASCII (e.g. accented, Cyrillic, Greek or ideographic) characters?

Normally, JoomlaPack tries to create the jpremote.s3db (the settings SQLite database) on the Documents and Settings\YourUserName\Local Settings\Application Data\JoomlaPack Remote folder. Please verify that this directory is writable. Also tell me if the jpremote.s3db file is there.

If it exists, it may have become corrupt. You can delete it (uninstallation doesn't remove it) and re-run JoomlaPack Remote. Of course, this approach means that you lose your settings, but I'm not aware of an easy way to check and fix an SQLite database file.

OK, since there is no file, the error message means that it can't create the file. Is there a JoomlaPackRemote.ini inside the application's directory? This file is normally used to run Remote in portable mode. So, if there is, Remote will try to create the jpremote.s3db file inside the application's directory. Since permissions are more strict in there, this might fail and give you an error. Deleting the INI file should let Remote create the file. The same applies if there is a jpremote.s3db file in the same directory as the application. Remove it too if it exists.

If this still doesn't work, there is some other filesystem related problem which doesn't allow the creation of the s3db file in the pre-defined location. In this case, you may want to use the ZIP version of Native Tools, extract is somewhere inside your My Documents folder and follow the instructions in the "Using Remote as a portable application" section of the documentation. Specifically, you'll have to create a text file named "JoomlaPackRemote.ini" with the following contents:

[Global]
Portable=-1

This will instruct JoomlaPack Remote to write its configuration file in the same directory as the application files. Since it's now a subdirectory of your "My Documents" directory, Remote should be able to write to it.

I have tried that on Windows XP Pro + SP3 at work, but I had no problem. This seems to be some obscure Windows permissions problem. Normally, the user has enough permissions to write to his own profile directory, or at least that's the whole idea of user profile directories. Normally, writing to the application's directory should be impossible, at least on the "Professional" variants of Windows :shock: I can't get why this workaround works :?

So far, I have met no problem with the standard configuration on XP Home SP2, XP Home SP3, XP Pro SP3, Windows 7 Beta. Lack of an affected system makes it very difficult to debug it, or at least figure out what's going on.