Upload error in 7.01.0009

Minor bug in sc_lookup

Another bug found:
I put in my code (for oracle to find the database I am working in) so with SINGLE QUOTES:
sc_lookup(rs,‘select lower(substr(global_name,4,3)) from global_name’);
This causes an error
ERROR
ociexecute(): ORA-00900: Ongeldige SQL-statement.

The generated code:
$nm_select = “‘select lower(substr(global_name,4,3)) from global_name’”;

I put this in my code so with DOUBLE QUOTES:
sc_lookup(rs,“select lower(substr(global_name,4,3)) from global_name”);
it goes fine…
The generated code:
$nm_select = “select lower(substr(global_name,4,3)) from global_name”;

So there is an obvious minor bug there…

I am attempting to catch the proper event using OnValidate (occurs first) OnValidateError (occurs if wrong after OnValidate) and OnValidateSuccess (occurs afterif so called succeeds but it fails with certain characters) and then BeforeInsert or BeforeUpdate (depending on what occured).
So everything above chr(127) I want to change myself. Everything containing a + or an &
The nm_mostra function is the place where it parially goes wrong:
function nm_mostra_doc(campo1, campo2, campo3)
230| {
231| while (campo2.lastIndexOf("&") != -1)
232| {
233| campo2 = campo2.replace("&" , “Ecom”);
234| }
235| while (campo2.lastIndexOf("#") != -1)
236| {
237| campo2 = campo2.replace("#" , “Jvel”);
238| }
239| while (campo2.lastIndexOf("+") != -1)
240| {
241| campo2 = campo2.replace("+" , “Plus”);
242| }
243| NovaJanela = window.open (“grid_filestorage_doc.php?script_case_init=<?php echo NM_encode_input($this->Ini->sc_page); ?>&script_case_session=<?php echo session_id() ?>&nm_cod_doc=” + campo1 + “&nm_nome_doc=” + campo2 + “&nm_cod_apl=” + campo3, “ScriptCase”, “resizable, scrollbars”);

But!! that is not the only place… As mentioned any above chr(128) go wrong as well, that would actually need an utf8_encode I think.
I think you can change it by hand with some fiddling in the code using the events (which is what I will do).
So basically all weird characters are to be translated to normal ones… And then the table field needs to be updated by hand I guess…

Advanced deployment notes for others to learn from since I had some problems with it

A warning for people who do the advanced deploying:
If you do an advanced deploy then the default paths are as follows (those entries are empty then!):
Common Libraries Folder:
web_application_path/_lib/prod
Images Folder:
web_application_path/_lib/file/img
Temp Folder:
web_application_path/_lib/tmp
Documents Folder:
web_application_path/_lib/file/doc

This is badly documented so be aware. Below a piece of the code that arranges the paths for my grid_filestorage application


      if(empty($_SESSION['scriptcase']['grid_filestorage']['glo_nm_path_prod']))
      {
              /*check prod*/$_SESSION['scriptcase']['grid_filestorage']['glo_nm_path_prod'] = $str_path_apl_url . "_lib/prod";
      }
      //check img
      if(empty($_SESSION['scriptcase']['grid_filestorage']['glo_nm_path_imagens']))
      {
              /*check img*/$_SESSION['scriptcase']['grid_filestorage']['glo_nm_path_imagens'] = $str_path_apl_url . "_lib/file/img";
      }
      //check tmp
      if(empty($_SESSION['scriptcase']['grid_filestorage']['glo_nm_path_imag_temp']))
      {
              /*check tmp*/$_SESSION['scriptcase']['grid_filestorage']['glo_nm_path_imag_temp'] = $str_path_apl_url . "_lib/tmp";
      }
      //check doc
      if(empty($_SESSION['scriptcase']['grid_filestorage']['glo_nm_path_doc']))
      {
              /*check doc*/$_SESSION['scriptcase']['grid_filestorage']['glo_nm_path_doc'] = $str_path_apl_dir . "_lib/file/doc";
      }

So suppose I have a project with many applications called ‘myprj’ which I place in …\www so that I get …\www\myprj
Then you either do not set the paths on advanced deployment in which case they default to (by the code in my grid_filestorage.php file, in the first couple of lines) and later on (see above)
Common Libraries Folder:
/myprj/grid_filestorage/_lib/prod
Images Folder:
/myprj/grid_filestorage/_lib/file/img
Temp Folder:
/myprj/grid_filestorage/_lib/tmp
Documents Folder:
/myprj/grid_filestorage/_lib/file/doc

If you want it different then you need to set the paths by hand… In which case you may opt a more global lib if you have more projects running for example:
Common Libraries Folder:
/_lib/prod
Images Folder:
/_lib/file/img
Temp Folder:
/_lib/tmp
Documents Folder:
/_lib/file/doc

This is not properly documented so be aware for mistakes.

Hello,

The ‘typical’ publication uses a default value for paths, if you do an advanced publication informing all paths correctly will work.

Referring to problem with symbols, we release fixes recently for some symbols and we are working on the rest.

*** the rest ***

  • if you fill all of those advanced fields then it does not work
  • use url encode / decode

Agreed that they will work, but it isnt described where your _lib then has to be if you dont fill any values in there. It is not mentioned clearly so therefore I did that. I think it should be mentioned properly in the manual. But I could only find that out by digging in the code and seeing what happens in detail by filling in the values and checking against my paths.
Now anyone that reads the post should be able to figure it out without digging in the generated code.

The character strings with strange characters are annoying.
When I upload a file with some stange character in it like ? then I get a Validate event and a ValidateError event but the {FILENAME} field which I use seems to be empty.
I guess $this->filename_ is going wrong in the upload_img_doc routine.

How is the status on this issue?? I mean the UTF8 encode to ISO-8859-1 or win1252 (actually it should convert to the characterset of the server computer)

To show the issue you can watch the following movie:

http://www.scriptcase.eu/FilenameError.mp4

Version 7.0.1.0011: the bug with the global variable in the comment still exists.
My comment:
/*
[grid_filestorage_help]=“Kies het kleine prullenbakje om een record met het bestand te verwijderen.<br>
Kies Browse om een nieuw bestand te uploaden, kies daarna het mapje met het pijltje om te bevestigen.<br>
De bestandsnaam zal daarna worden getoond.<br>
Kies de bestandnaam zelf om het bestand op te halen.<br>
Toegestane bestandstypen zijn; jpg;bmp;doc;rtf;docx;xls;tif;xslx;gif;pcx,txt”;
*/
This causes a global variable to be added… So it is a bug. I thought it was fixed?? It also fails with:
//[grid_filestorage_help]="Kies het kleine prullenbakje om een record met het bestand te verwijderen.<br>

Please dont reintroduce introduce bugs on something I that was fixed.

Another bug?? Apparently when you create a document upload field the code that is being created never calls the move_uploaded_file function
so the temporary directory (in scriptcase/tmp) gets filled with sc_…_myfile.jpg and such files…
Can someone please explain me what this for non standard behaviour is? It is normal to use the mentioned function to move an uploaded file to the proper directory.

If a file gets uploaded to the temporary directory then it is NOT utf8_encoded so any character above 127 will be utf-8 instead of win1252 or iso-8859-1. Please fix.

In SC6 this worked: I have a document filename field and I set disabled field to update mode.
Then when I run my app I can not update that field since the field is properly disabled.
In SC7 I can still update that field, no matter what I set… !!
Another bug…

You’ll get a movie about this bug as well. Make me happy and resolve it… sigh…

[QUOTE=rr;19672]Version 7.0.1.0011: the bug with the global variable in the comment still exists.
My comment:
/*
[grid_filestorage_help]=“Kies het kleine prullenbakje om een record met het bestand te verwijderen.<br>
Kies Browse om een nieuw bestand te uploaden, kies daarna het mapje met het pijltje om te bevestigen.<br>
De bestandsnaam zal daarna worden getoond.<br>
Kies de bestandnaam zelf om het bestand op te halen.<br>
Toegestane bestandstypen zijn; jpg;bmp;doc;rtf;docx;xls;tif;xslx;gif;pcx,txt”;
*/
This causes a global variable to be added… So it is a bug. I thought it was fixed?? It also fails with:
//[grid_filestorage_help]="Kies het kleine prullenbakje om een record met het bestand te verwijderen.<br>
[/QUOTE]

Hello,

Try clearing your browser’s cache, we perform several tests locally and did not occur in this problem.
If the problem persists, tell me how you are doing. Notify application that this problem is occurring, and where you are telling this commented code.

[QUOTE=rr;19689]In SC6 this worked: I have a document filename field and I set disabled field to update mode.
Then when I run my app I can not update that field since the field is properly disabled.
In SC7 I can still update that field, no matter what I set… !!
Another bug…[/QUOTE]

Hello,

Thanks for making the video, I appreciate it.
The problem has been registered in our system and we are waiting for the fix, to release in the next updates.

YES!! you make me happy… Be aware tho it is delved pretty deep I have been digging deeply into the generated code and found several issues (as you have seen).
-the filename issue where & + % and characters above 127 fail
-the issue where files are uploaded in my grid but the directory where the uplaods occur seem to be either a temp directory or the real one where I want to upload where it actually should be the real directory. (also serious!).
Well you can check the movie…

Well that was my temporary happy feeling. I just did the update to 7.01.0013 and there are still lots of the reported bugs in there…
Please fix the bugs…

[QUOTE=rr;19952]Well that was my temporary happy feeling. I just did the update to 7.01.0013 and there are still lots of the reported bugs in there…
Please fix the bugs…[/QUOTE]

Hello,

I said that your problem has been reported will be fixed in the next updates.
The developer has not released the fix to test, I ask that you wait a little longer.

I’ll wait, this way I may not have to replace the whole module with the jquery uploader.
Please also take into account that the delete of files also has to be tested on files with strange characters. That is an issue that is often forgotten…