Bug with masters-details is SC.

Hi, i have an app master-detail working fine, if i add a new item detail, its add the new record with the number (foreign key) of master.
But If i open other app and then return a my master-details previously opened and add a new item in detail. This asign value ZERO to Foreign key (key of master). so the new record saved has foreing key ZERO and do not shown, if i open the form master - detail again.

I have a system in production and i got ths error with SC7.
I did the same example with SC Examples opening your master-details and opened other app and i got same error.

Add Image of SC Examples Mater detail SQL For Orderrs Details

ErroSC master detail.PNG

Hello,

Issue reported to our bugs team.

regards,
Bernhard Bernsmann

Hello,

I could not understand well as simulate your problem so I can explain to development sector, so would like you to inform me step by step how to perform the procedure from the bug mentioned in this topic. Thanks for understanding.

If possible, please attach pictures of step by step how to simulate.

Thank you!

My user have this problem and i need fix it!!.

The problem if you have an app master-detail opened and have details in your app AND you open other APP simultaneously and then you return to app master detail and create a new record… and save. THE NEW RECORD SAVED in detail has foreing key value ZERO.

Please see imagen in this Thread. (I tested with your examples and This error is Shown too)

Do you mean that you are opening another app in a different tab of the browser?

Dave

Yes, exactly. These a Bug because the primary key of master is converted to ZERO when you open an app SC in other window of browser.

This problem you are seeing has nothing to do with Scriptcase. It has to do with the php session id. You are sharing globals between the two tabs.

It is inherent in the way that browsers and servers work. The server sees both tabs as one session. You are using the same session ID when you open multiple tabs in the same browser.

The server (and php) do not know that you have opened another browser tab, they see the requests as coming from exactly the same place.

Both of the tabs will be using exactly the same session variables (i.e., all of your scriptcase global variables).

That is how browsers and servers work. Scriptcase cannot change that.

Two things can help you out - Firstly, you can run two different browsers. Since they do not share the same session, they have separate globals and everything will work fine.

Secondly, you can use the browser’s capability to use “anonymous” tabs - in Firefox this is called a “Private Window” (under the File Menu) - in Chrome it is called an “Incognito Window”. These windows do not share php’s session identifying cookie, and thus look like different machines to the server.

You can also mitigate bad things happening by multiple tabs in how you design your system and how you use globals.

Google “php session collision multiple tabs”

Dave

Hi, Dave,
I am not sharing global variables.
If the App “A” (master-detail) is opened and has records in details. the detail has a foreign key equivalent to (primary key of master).
Now you open other App “B” and RETURN to App A again. THEN
When you insert a new record in detail the Primary key of master is converted to ZERO. and if you save changes, It show an error because the ZERO by referential integrity.

You can see App “B” do not use any variable. Just is used to change of window.

But the variable in APP “A” Changed the value of variable in your same session.

Your system IS sharing them, whether you do it intentionally or not. That is how browsers work.

Sessions are ALWAYS shared between multiple tabs open in the same browser that reference the same website.

You can prove this to yourself by logging into facebook in a browser, then open another tab and log into a different facebook account in the second tab. Everything goes to hell.

It is not Scriptcase, it is the way that browsers and servers work. Scriptcase can do nothing about it.

Dave

Ok. Thanks you Dave.