Problem with MS SQL and Image field loading

Scriptcase 8 Discussion
#1

Hello,

We are using Scriptcase 8.1 Enterprise edition and I have stumbled upon a problem related to the Image field. We are using a form to store images to the Microsoft SQL server. The upload part seems to be working as it should be, but for some reason the images are not displayed after the upload on any of the forms it should be.

First I thought this was problem with database column type, but so far I have tried to use binary, image and varbinary(max) data types, with out any luck. The upload part works for all of them but it is not displaying the image.

I also tried running the project through Internet Explorer, Firefox and Chrome, all with same result. In the field the image is supposed to show up there is only an image icon with broken corner and when the icon is clicked the ajax processing bar appears and runs on forever, with out loading anything. I have also checked that the browser are allowing use of javascript, images and are not prefetching any data through domain-DNS or caches.

The project was started to develop on top of MariaDB (MySQL), but because of our client environment we had to migrate to MS SQL. Everything else seems to be working for now, just this image issue has risen up.

#2

I would suggest using the developer edition of Firefox and inspecting the image and surrounding HTML (before and after clicking). Perhaps it can give you a clue as to why the image is not displaying.

#3

I’m also using MSSQL. I tried to duplicate your issue but it works ok for me…I created a table with 2 fields, ID (int data type) and imagetest (image data type) then went into scriptcase and created a form using that table. Upload works ok and the image shows up. I’m using chrome.

#4

I noticed that upon image loading scriptcase creates temporary file in /scriptcase/tmp folder (in server) of the image. I need to check the folder permissions are they high enough. I’ll post back here after I get some results.

#5

So, I have checked my folder permission and everything seems to be in order. I also noticed that the server created the temporary file inside the tmp folder as it should be it just does not contain anything (only shows image with X). I also tested image uploading with test database table that only contains id, filename and doc_data(varbinary).
Results are similar as before, uploading works, but this time the image really does show up in the form after the upload. When I hit refresh in the browser the reloaded page shows only the broken image icon, same as in our application. On our other developement machine this works as it should be, that one is deployed outside of our clients domain (however, this machine is using mysql).

So either our MS SQL installation is missing some configuration needed for the image data to be reader/writed correctly, or something in our clients domain is supprerssing necessary privileges.
I have compared the browser setting between the computers and they all match, also the folder permission match, with one expetion our other machine has windows 10 and it is showing group “ALL APPLICATION PACKAGES” as one of the authorisized group. Our other machines uses Win 7 and and it does not have this group in it. Anyone has any suggestion, I really need to get this problem sorted out because image/document uploading/downloading is one of key features in our current project

#6

Okay, so it seems I solved it. The folder permissions were correct. I tried uploading the image through MS Management studio with direct SQL query and noticed that this time the image did show up, just not completely (about 90% was blank). Came to a conclusion it had to have something to do with data column capacity (although the images were small, around 100kb).

So I went and created new database and table with the Filestream property enabled + configured and this time it worked with out any problems.

EDIT:
Tried this with application database with filestream file in SQL Server default folder path and no luck, still not working. Back to researching the permission side.

#7

I checked the table I used for testing this, no filestream property. Could your issue be web server-related? such as php.ini post max size? I’m just shooting in the dark here.

If you want to compare mssql settings or whatever, just let me know where to look, I can check my setup.

#8

This is frustrating one. I will have to get back on researching this problem tomorrow, but yes, any help you could provide would be greatly appreciated as this is starting to set out project back.
I currently have tried this on the main server where the app is being deployed and our development machine that is inside domain, and both have the same problem.

#9

Okay, so now it is finally solved, folder permission were right, and so was the server configuration (filestream not required). The reason for the images not showing was in the end found inside scriptcase setting,
When I was testing the database to solve this problem, I had to create new connection inside scriptcase. With this new connection the images displayed correctly. I was so sure that the problem lied inside the filesystem/permission side of the server that I did not pay attention to these connection parameters.

As it is stated in the Scriptcase knowledge base
3. Connection Native SRV (MSSQL Server Native SRV)
A Native SRV connection is the most recommend for use on Scriptcase. This type of connection has better performance, also the only one that works perfectly with the field type?s image and document (database)

Yep, that is right, this is what the new connection was using. The old one was set for “MSSQL Server” which is native PHP driver. Changing the driver for the old connection solved the image problem. Suggestion for Scriptcase folks, would it be possible to add warning when selecting the native PHP driver that images/documents may not work when using it.

But, nervertheless, there it is. Solved, took only a week, but hey, got really familiar with the MSSQL Settings :smiley:
If Moderators could mark this as solved that would be great