Programming attributes in grids vs forms

I’m using attributes (Programming\Attributes) for the first time.

It seems that while attributes can be used in the SQL Select Statement of grids, they cannot be used in the Where clause of forms apps.

By “cannot be used” I mean that they are not resolved at form runtime, resulting in a sql error:

1064: You have an error in your SQL syntax; …

SELECT field1, field2 from table_name where field3=’{my_attribute}'

Is there any solution?

I may be off here, but I think the single quotes need to be removed

you can use only global variables passed before the base form/grid query is executed.
The attributes/fields get values from the query, so how do you imagine where my_attribute value comes from?

select fields lookups is a different thing as grid/form query is already executed and the fields are already loaded

@maximnl
actually SC attributes are just session variables with the added “protection” that they are bound to the name of the app so that one can be sure that their scope is the running app only.
they just get converted to stnadard PHP as

$_SESSION[‘app_name’][‘attr_name’]

To make it work wit the SQL statement in grids I just do this:

in the app onAppInit ([param_id] is passed by the calling app)

{attribute_id} = [param_id];

in the app SQL statement

… WHERE id=’{attribute_id}’

By using attributes instead of directly referencing the parameter name, it’s safe to use simpler parameter names (e.g. [param_id]) in multiple different apps running at the same time (in different tabs), without risking overwriting the same parameter.

2 Likes

I conform, attributes are not working in the form sql where, just as u said.
i set up an attribute in onapplicationinit, so it should get value before the query is run.

somebody said that if you uncheck the global variable session type , it will become stored in the app only, probably acting as an attribute exactly.
it is a bit confusing that attributes have the same syntax as the fields, but you outlined good reasons to have them.

i do assume sql/where expression with a global variable in it is compiled only once on applicationinit and not changing if the global variable is changed somewhere else.
it would be great to know what is causing sql where expressions to revalidate?

Maximnl what robydago is saying is very important. If you assign a parameter to a global variable on AppInit and then use the parameter and not the global variable in all your code (also in the sql ) it gives you the possibility to run multiple apps in multiple tabs without risking global variable collisions in the session

This is something I could investigate.
But when you have many variables in an app, the SC interface to check\uncheck the variables settings is really cumbersome.

with grids it could easily happen: e.g. after editing a record in a form app

But what about the exact same app (app_name) opened by different apps in different tabs?

This is something I really don’t know how to solve.

Event attributes will be the same: $_SESSION[‘app_name’][‘attr_name’].

1 Like

Same app in two different tabs in same session is not possibile.
The two same apps will interfere against each other and collide because of the underlying same session behind.
It is not an issue with SC/PHP but it is how http cookies session work

There are solutions anyway.

  1. Open the apps in different URLs. You just need to configure your dns or hostfile or apache server to point to the same server using different urls. Say myserver1.com and myserver2.com having same IP address. in such case the sessions will be different and you can have the same app running in two tabs at the same time. You can run as many identical apps as urls available.

  2. Use two different browsers or incognito mode (this is not really a good solution I admit)

1 Like

@maxi

both your solutions don’t seem feasible to me:

  1. issues with authentication: multiple URLs will require multiple logins (i’m using MS azure authentication)
  2. too complicated\cumbersome for end users

I think a better solution would be for NetMake to create a new kind of apps: “linking apps”.
In the SC IDE they would be just a link to an existing application and the only setting in the linking app would be its name (thus a different\unique name) and which app it links to (the “real” app).

When compiling\deploying the linking app, the SC IDE would create all standard dirs\files as normal apps but using the linked (real) app as source. The generated dir\files names and the files content would use the linking app name instead of the linked (real) app name.

In this way we could create as many linking apps to the same real app as needed.
By using a different linking app name in the settings of each app that opens the same real app in a different tab, there wouldn’t be any conflict.

Note that I’m talking about SC apps tabs, not browser tabs. That’s why the programmer has control on which/how many different tabs will open the same apps

actually if you name tabs differently it will open same app but in different tabs.
another way is to use menu. try to make several menus opening the same app, app1, app2, app3, linked to the same app. allt three will open three tabs. it is just not that great to make several menu items , but ok, this is a work around if you want to work with the same app but different filters for a grid instance.

While reading your idea I am asking myself : what happen if in the server hosting app1 you create a file system link from app2 to app1 ?

From the browser you will have two urls:

www.myhost.com/app1
www.myhost.com/app2

but app1 and app2 share the same code and files on the server.

What about attributes in session ?
Will be kept separate?

@maximnl

My typical usage scenario is this, starting from the menu items:

INVOICES → opens grid G_INV in menu tab “INVOICES” → opens form F_INV in the same tab → opens form F_ORD in the same tab

ORDERS → opens grid G_ORD in menu tab "ORDERS → opens form F_ORD in the same tab

So the same app (F_ORD) can be open in two different menu tabs (INVOICES and ORDERS).
And that’s why session variables, even with the app name in it, are not safe.

@maxi

the issues with just the file system links are two:

– I think the app name is hardcoded inside some of the files generated at compiling\deploying time.
– How can the SC IDE be aware of the app if it exists only in the filesystem? you need the app in the SC IDE to be able use it when you create links between apps or use the sc_redir macros, etc.

1 Like

I had same problem with session variables for same app opened at once. Here an old post over same problem. (I hope SC tea,m tell us How solve it).

1 Like