Hello,
since I updated to the version 8.00.0027 the following error appears.
In the grid I have an application link to the corresponding form.
If I click on the pencil to edit the record…the form window is opened in ADD-Modus … ??
This happens to all tables I tested…
Can anybody confirm this bug ??
Best regards
Uwe Pfeiffer
Hy Uwe,
I am sorry I cannot confirm thus bug.
I am using 8.00.0027 and all my forms, linked to the grids with an application-link (pencil icon), correctly open in UPDATE-Mode.
Thanks for your answer.
The error only apears when I call scriptcase development server using my browser…
for example :
http://xxxx.ims-firmen.de:88/scriptcase/app/SVSB/sc_login/sc_login.php?nmgp_outra_jan=true&nmgp_start=SC&script_case_session=e8k316qvku85lt54ilmo122eg7&4027
If I work with remote Desktop on my server the error is not there.
So must have to do with starting the development environment from extern… ??
best regards
Uwe
Weird. Has you assigned the id filed in link?
First try to clear all your cookies and cache. Then try again. If things are working with rds then it’s highly unlikely that a bug of scriptcase is the cause of this. Are you running two instances of the scriptcase applicaiton in your browser (cookie mixup?).
Hello,
Really strange
Bestregards
Uwe
Hello,
Internet Explorer last version for Windows 8.1 shows the same error…
Best regards
Uwe
As Albert sais, this no sense.
Can you share privately login information and Project and steps to reproduce it?
Hello,
after hours of debugging I think I found the error.
sc_change_connection (“mysqlconn_test”,“mysql_conn_atm”);
The command sc_change_connection in the OnScriptInit-Event of the single form is not working … it is ignored !!!
The form still remains on the -old- database… !!!
because of this fact the search ID (when you use the edit pencil) of the grid cannot be found in the form … and the form opens in ADD-modus !!!
the form still looks on mysql_conn_test --> and the grid works with mysql_conn_atm …
This error does NOT appear in remote Deskotp, but only if you DIRECTLY call your development application in the fom of http://xxxx.ims-firmen.de:88/scriptcase/app/SVSB/sc_login/sc_login.php
the same command is working properly in the OnScriptInit event in the grid !!!
a horrible vision…that changes of database are not handled correctly…
because most of the users don’t use sc_change_command … they are not affected by this error.
if you like and give me your skype-account I will contact you to show this error live !!!
my skype account is uwe_pfeiffer_brokstedt
Best regards
uwe
Uwe,
I have repeatedly reported this bug - see http://www.scriptcase.net/forum/showthread.php?7484-Macro-sc_connection_edit-bug-when-used-in-grid-onRecord-event
That post demonstrates the problem using sc_connection_edit, but I believe it is exactly the same logic error that you are seeing in the sc_connection_edit macro.
Any time that the connection is modified after the Application Initialization phase, it is ignored until the next Application Initialization when the connection is re-established.
I even built sample projects to demonstrate the bug and how to fix it, but I have not been able to get anyone at NetMake to do anything about it.
If you want a temporary workaround until they fix the problem, take a look at the sample code I put in the demo project.
Can anyone at NetMake respond please???
Dave
@uwe, you can connect to aducom-software for skype as we discussed before. It’s annoying that SC still hasn’t found a decent way to communicate regarding bugs. We too have posted issues with samples and are still waiting for response. A lot of issues has been cleared, but a lot of new ones (due to changes?) created. It was said that SC was trying to solve all issues before end of 2014, unfortunately there’s still a lot to do.
I figured it out and the documentation of SC concerning the command sc_chang-connection seems to be wrong.
If you want to change the database in a grid/form BEFORE THE SQL-STATEMENT IS RUNNING you must put the command to the event ApplicationonInit !!!
If you put it in the event OnScriptInit the command will be wothout effect on the SQL-Database of the SQL-Statement !
In SC-Webhelp this command should be placed in OnScriptInit … and this is wrong in my opinion.
[QUOTE=Pfeiffer;30912]I figured it out and the documentation of SC concerning the command sc_chang-connection seems to be wrong.
If you want to change the database in a grid/form BEFORE THE SQL-STATEMENT IS RUNNING you must put the command to the event ApplicationonInit !!!
If you put it in the event OnScriptInit the command will be wothout effect on the SQL-Database of the SQL-Statement !
In SC-Webhelp this command should be placed in OnScriptInit … and this is wrong in my opinion.[/QUOTE]
If this is true then it’s not very consequent as you cannot use db statements in the onapplicationinit because there’s no connection whatsoever. It looks like this ‘feature’ was designed in a rush.
Hello Albert,
that makes sense
The only error is, that this command must be placed in OnApplicationInit AND NOT in OnScriptInit Event.
I Think the WEB help for SC is wrong in this point.
Best regards
Uwe
Uwe,
In your particular case, that is an adequate workaround, but actually the effects of the bug go much deeper than this.
I also have many databases, all structured alike, and the information for the customer’s database is set at login time.
Now, think about the case where I (as administrator of many accounts) want to display a grid that lists each account, database connection parameters, and the total number of records in a particular table of each account (In my case, Employees).
Because the connections are only established during the Application Init phase, any of the connection modifying macros in the grid’s onRecord (even for databases that are not the Primary Database/Connection for the Application) are ignored until the next Application Init. To see this in action, look at the sample app I created for this post .
The fix for the flaw in the scriptcase logic is as follows:
When you modify a connection using any of the connection modification macros, the underlying logic should be setting a flag so that the very next read/write using the affected connection forces a re-connect using the new connector information.
I proved this in the workaround that I supplied in that project. It should be only take a few minutes for NetMake to correct the macros involved, if only someone would give a copy of it to the developer responsible for the connection macros. So far, after more than a month, I cannot get anyone at Scriptcase to listen.
Netmake, please. I know that I may not have expressed myself clearly in these posts, that is why I created the demo project to show exactly what is happening and how to fix it. Even if you do not understand what I am saying, please give the demo project to the developer responsible for the sc_connection_edit macro and he will understand what I am trying to demonstrate. Links for project & database setup are here.
Dave