I no longer received any errors and nor did it update or ins

I am newbie to dhtmlx and after downloading the Pro edition a week ago I am working my way through all the components using the samples as provided. These problems are in your samples and other for changing the database password in the config.php I have not made any other changes to this sample - dataprocesser.
So forgive my newbieness and frustrations when provided samples don’t work as expected.
I included the ‘dataproc.enableDebug(true)’ in the code here:
//init dataprocessor and assign verification function
myDataProcessor = new dataProcessor(‘php/update.php’);

I no longer received any errors and nor did it update or insert records into the table. I don’t know what the debug option was supposed to do. Other than inhibit actions on the database there was no other evidence it did anything

>> //init dataprocessor and assign verification function
>> myDataProcessor = new dataProcessor(‘php/update.php’);

replace this code with

myDataProcessor = new dataProcessor(‘php/update.php’);

Updated code to
            //init dataprocessor and assign verification function
            myDataProcessor = new dataProcessor(“php/update.php”);
            //add after-update event handler

The only observable effect is that you can build the tree on the client side without error but nothing is getting written into the database. (As stated previously).

The sample code get.php and update.php may be applicable for your public site for people to ‘play’ with but it is NOT USEFUL for downloading and installing locally in a development environment! It would appear that enableDebug(True) interrupts all communication with the database. I downloaded the Pro edition and installed into my web running on my localhost.

This morning after restarting my computer I could no longer see any part of the tree. I checked the table in the database and confirmed that all records from the previous day were persisted. I ran the get.php and observed an empty XML tree. I checked the get.php code and noticed - GUID=’".$_SESSION[“id”] . Silly me. Here I was thinking that the column in the database named GUID actually stood for Globally Unique IDentifier. Remember my first post re GUID.

I replaced the GUID=’".$_SESSION[“id”]."’ with True in get.php and was able to retrieve yesterday’s records.

Unfortunately, doing the same minor code change in update.php did not fix the problems experienced when Inserting, Updating and Deleting nodes.

I confirmed that what ever you have running on your public web site produces the results as expected. I even got to see messages appear in the grey box next to the treebox. In my local installation I see no messages whatsoever.

From javascript perspective

are two different commands. “True” ( with capital T ) will be treated as unknown identifier and will throw js error, which block any further commands.

>>but it is NOT USEFUL for downloading and installing locally
the code used in online sample and included in package is the same code - it requires PHP and MySQL to run, but not any otherprerequisites

Thanks for sorting out the java variables (just an old habit for writing “True”).

This time I did receive some debug errors. Please refer to the following gallery - hsyst.com.au/gallery/main.ph … itemId=629

The following figures are resultant of the subsequent addition of .enableDebug(true); in the update.php
Fig. _insert_11
Shows first message

Fig. _insert_12
Shows next message

Fig _insert_13
Last message. This is the error message received as indicated in my initial post.
The database indicated that “New item” had been inserted into the table.

The node in the client-side tree was still showing bold
Editing the record would result in the database being updated but the node would still be bold

Messages are not displayed in the grey box to the right.
I notice on your public site that there appears to be a refresh event when entering new nodes.

I will leave it to you to interpret the debug messages and I’ll move on to the following as suggested.
Please check “XML loading” section of next article 

Response shown at Fig. _insert_12 is incorrect
It must contain real values , not PHP tags

It seems that somehow , server side conde outputs the message without replacing PHP tags with actual values.
Please be sure that your php installation configured to process PHP tags ( such options must be enabled by default )

PHP 5.2.5
My settings are:
xml Support = Active
xmlreader = enabled
xmlwriter = enabled

You need to change next option
or change the server side code and replace short tags with plain PHP code

short_open_tag=on changed the behaviour of the update.php to pass writes through to the database and therefore persist the update.

I left my php.ini setting to default off due to the following excerpt from the php.ini file:

; NOTE: Using short tags should be avoided when developing applications or
; libraries that are meant for redistribution, or deployment on PHP
; servers which are not under your control, because short tags may not
; be supported on the target server. For portable, redistributable code,
; be sure not to use short tags.

I don’t use short tags in my code.

The screenshoot at
hsyst.com.au/gallery/main.ph … itemId=666
Shows such response as
<action type=’<?=$action?>’ …
While it must be
<action type=‘insert’ …

It seems, that your server side code doesn’t replace <?=$action?> with related PHP value.
You need to replace code in update.php, which used to output type, sid and tid parameters , with one without short php tags

Thanks for pointing that out - now I understand a little more.

However, I stand by my statement that I don’t use short tags. Referring back to my opening question I’m “using the samples as provided” by you - so the update.php is your code and looking more closely of your code I notice it is using short tags.

Given that I have 30 days to evaluate your components I don’t want to have the frustrations of debugging your code - I want to focus on evaluating the component features and functionality. I have now moved on the look at the Grid and have been dealing with similar issues.

Needless to say, I am impressed with both the components and your support.

I’m “using the samples as provided”
Which sample you are using as prototype? The grid’s package includes dhtmlxGrid\samples\dataprocessor\dhtmlxGrid\samples\dataprocessor\savedata_grid.html

>>so the update.php is your code a
dhtmlxGrid\samples\dataprocessor\php\update.php line 87+
print("SQL query error");

As you can see there is no any short php tags. But in your screenshot the server side code outputs php tags instead of inline values.

update.zip (1.33 KB)

Up until your last post (a=7255) all comments related to the dhtmlxTree.

I have attached the original update.php file.

update.php.zip (1.53 KB)

Sorry for inconveniense, I talked about dhtmlxgrid’s files, not about dhtmlxtree.
The code used in samples of dhtmlxtree is really using short tags, updated version, without them, attached to email.

update_fx.zip (1.54 KB)

Thanks for the update. Now that I’m aware of these little “gotchas” it’s no longer an issue.

Thanks for your support.