I exported my solution from developer then used the server admin page to import it to the remote server. Then I run the smart client via the jnlp. The solution loads and runs but all the images used on buttons logo etc are not displayed. Is there some other permission setting that the Servoy app server needs on Win7. I have installed the app server as a service with the correct permissions (administrator rights).
There are no messages in the app log for this.
Win7 64 bit, Postgres 9.0, Servoy 5.2.1
What am I missing this early morning before coffee?
where do the images come from?
are those just images that you have inside your solution ?
those should display fine.
The images are in the media of the solution. In developer they display fine.
When I examine the .servoy file I see the blobs - assuming they are the media images.
I notice that one of the files has a file name of this form:
abc-def.png
When I duplicated this image from the solution media to another module I got the error message that the name was invalid. (The solution came from a version 4.x solution imported into 5.x)
The exported solution that I made was before I attempted this media duplication. So perhaps on import this file fails to be stored on the server and causes all of the media to be aborted loading?
hard to say then, you could create a case with that solution file so that we could see if the file is correct.
Ok then I will make a case after a couple more checks of my own:
1.I am using Postgres as a stand alone server.
2.In the Servoy app server admin page I have set to false the property ‘use servoy repository as Team Provider’.
Where are images stored on the server due to am import via the Admin pages?
Can I check that the blob images are being loaded in that folder?
EDIT: added case 324386
they are stored in the repository database if you load it through the admin pages
Thomas, Johan: I have come across a possibly related example, though my scenario is different.
Using many of the images in SvyCore, my solution has SvyCore as a module. The solution is running fine under Servoy 5.4.1 on a Windows SBS2003 server.
Under development is an upgrade. Development regime is Mac OS X, Servoy 5.2.1 and postgreSQL 9.0 (stand alone). The upgrade works well on Mac using smart client. All media appear as expected.
I have installed Servoy 5.2.1 and postgreSQL 9.0 (again stand alone) on SBS2003 in readiness for the upgrade. I transferred the repository and separate required databases using pg_dump from the Mac cluster and pg_restore into newly created dbs on the Windows cluster. Testing the solution using (new) clients on SBS2003, I find that functionality is fine, but images are missing.
Digging into the servoy_media table for an example, I have recorded media id=2 on both OS X and Windows platforms. In the attachments I show firstly the media_data bytea value; below is the media_hash value. Servoy engineers will know how these are used. However, I notice that the media hash values are identical. I would have expected the values of the media_data to be the same for the two platforms, but they are remarkably different.
Might this be a postgreSQL 9.0 issue, where pg_dump treats blobs differently on the two platforms?
servoy_media_id_2_win.txt (1.67 KB)
servoy_media_id_2_osx.txt (2.58 KB)
I thought I had replied to this thread with what I believe was the solution in my case.
The simple solution was to replace the Servoy 5 provided Postgres jdbc driver with another driver that is compatible with Postgres 9.0 (apparrently the Servoy Postgres is 8.4 as delivered with version 5.2.2) - I use the x64bit version of Postgres 9.0
I got the updated driver from the Postgres website, copied into the Servoy drivers folder and had to remove the driver for 8.4 since it seems they have a similar name. After that all the images were properly retrieved and delivered to the smart client.
Perhaps this helps now?
Thanks for your update Thomas.
Following your proposed solution, I replaced the Postgres jdbc driver by the latest JDBC4 Postgresql Driver, Version 9.0-801 from http://jdbc.postgresql.org/download.html. As a precaution, I removed the postgresql driver included in the Servoy installation. Servoy Application Server started as usual. However, my smart client remains unchanged, showing images broken throughout the solution.
Examination of servoy repository using pgAdmin shows that the media are all there, though with unexpected bytea data.
maybe that byte data is somehow truncated?
Can you see the length in both repository tables of the same image?
Hi Johan - you can see an example in the attachments to my post of 10 October 2010. These show you the length and detailed content.
Note the title of the attachment, which gives the image ID and the platform. The text file content gives the bytea content as a block of text, then an empty line, followed by the hash value. The bytea value is as revealed by pgAdmin installed on the appropriate platform, local to the server. I am not aware whether or not pgAdmin itself truncates. Note also that the hash values are identical in the two attachments, but the bytea values are very different. I do not know whether this is a result of platform dependency, or an erroneous transfer of BLOB data through the mechanism of pg_dump on OS X and pg_restore on Win 2003.
then the images look wrong, you see in the mac byte dump that it is a gif but the win dump is totally different, so if we really look at data that is really in that column (no conversion or encoding over it) then there is something wrong. Maybe you can not do it with dump/restore but with a servoy file from 1 to the other.
Thats even better because what you create is a exact duplicate of the repository, that shouldnt be done.
If I understand you correctly Johan, I should not dump and restore the servoy_repository database from OS X to Win; but it is OK to do that for the solution databases?
I have application server on the production server; developer not installed. To clean up the repository, will it be sufficient if I delete the solution and its modules from the application server admin/solution page; and then reload the solution file? Or would uninstallation and a totally clean start be the way to go?
solution databases are fine.
if that dump/restore is only there to move the repository database thats fine, but if that is to create a copy, dont do that…
Why dump/restore seems to mess up your images i don’t know, so you could try to import/export a solution file.
When I moved my solution over to use Postgres x64bit server I used the export/import and this did not corrupt the images. Perhaps the dump from the old version to the new version of Postgres are not compatible?
Johan is right (of course!). Thomas’s point about compatibility might be worth investigating. However, I now have a working procedure to resolve the problem.
My intention had been to transfer a PostgreSQL 9.0 servoy_repository database from a development environment to production using the PostgreSQL dump and restore mechanism. Although the procedure worked and reported no problems, the resulting configuration did not show any images - button images, for example.
My development system is OS X 10.6.4. PostgreSQL version 9.0 installed separately from Servoy, using an installer from enterprisedb.com. Servoy 5.2.2 with PostgreSQL JDBC driver replaced by postgresql-9.0-801.jdbc4.jar.
Operational environment is Win2003 server, Servoy 5.2.2, with postgresql-9.0-801.jdbc4.jar driver.
The key to successfully displaying images in clients is (in my case) as follows:
-
Create in the production server’s PostgreSQL cluster a new servoy_repository db.
-
In a command window, run servoy_server.sh -upgradeRepository to create the repository tables.
-
Start Servoy application server service.
-
Import the solution into the new (empty) repository using the admin server’s solutions webpage.
Note: I exported the solution from Serclipse, including authentication, login and SvyCore modules, and users.
Okay, I did a bunch of tests and it turns out that it’s the jdbc driver that Servoy ships with Servoy.
When using PostgreSQL 9.x you should use the latest jdbc driver as well.
You can download it from http://jdbc.postgresql.org/download.html (JDBC3 should be fine).
PostgreSQL 9.0 has a new server setting for bytea columns (bytea_output). This can be set to ‘hex’ or ‘escape’. Hence the differences in binary data (format only, the actual data is the same).
The new driver will give proper binary back in either case.
Robert has drawn attention again to the importance of using the correct JDBC driver for PostgreSQL version 9.
In my scenario of a migration from development to operational server, the correct JDBC driver is necessary but not sufficient. To read the media in the servoy repository, the repository must be built in the correct way (see Johan’s comments above and my process steps outlined above).
Using PostgreSQL pg_dump and pg_restore for the servoy repository did not produce readable media images in my scenario, even using the correct JDBC driver.
Hi Richard,
This is really strange. I could reproduce your issue and fix it.
I dumped a repository db from my Mac and restored it on Windows. Both using PostgreSQL 9.0.x.
On the Mac I already used the latest driver, but not on Windows. Also my bytea_output was set different on Windows so I saw the same differences in binary (output) data.
Using the latest jdbc driver on windows solved all this, whatever I set the bytea_output parameter to.
So I am not sure what you are doing differently. Did you remove the old PostgreSQL driver from the drivers directory ? You should only have 1 Pg driver in there.
Also what if you restore the backup on the Mac into another database. So in the same Pg instance it came from, does it show correct image media then ?
Hi Robert
Thanks for your observations and questions.
To clarify my use of the new postgresql driver, I confirm that in my earlier tests I removed the old driver before attempting to use the new version. The problem I encountered occurred with a restoration from a dump of the repository.
Following Johan’s advice, I am no longer restoring the repository from a dump, but rather creating a new repository and then importing the solution. This procedure works well, though is not nearly as quick as using pg_restore from a dump file.
I have repeated the migration procedure again today from Sybase v10 via v11 to PostgreSQL v9.0 using solution ‘all rows’ data for migrating the tables; and using the new jdbc driver, fresh install of Servoy 5.2.1, and creating a new repository: on both Mac (as a staging test) and then on the Win2003 production server. It is a long process, but it works well.
For those who are interested, I use Sybase Central for some preparatory tasks, including unloading v10 into a v11 Sybase database. Servoy Developer exports the current solution and all the data. Using a new install of Servoy 5.2.1 I then import the solution into a newly created repository database and new dbs for the client’s data. I have worked up a new version of the solution which has PostgreSQL SQL dialect rather than Sybase, so the next step is to import that solution (which includes enhanced security login and authentication modules). At this point the migration of both data and Servoy solution has been completed without the use of any proprietary data migration tools other than Servoy. The Servoy engineering team deserve our gratitude and congratulations for the excellent way in which the current version (5.2.1) handles the transfer.
In the course of migrating client data I will defer trying your last question concerning restoring a dumped repository into a new database, but it is an interesting question. Johan was cautious about it, so I am avoiding this action in my current process steps.