 | |
Get(accountname) problems in IWP
comp.databases.filemaker comp.databases.filemaker
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Get(accountname) problems in IWP -
02-11-2007
, 12:22 PM
|
Do you have more users then User1 and User2? If not then try to replace the Else If with an Else. I see what you are doing and have a question. The user gets presented with a found set, based on his/her AccountName. Is this failsafe for you? Is there no way the user can change this found set along the way? I don't know how your tables are set up, and don't know if it might be practicle, but perhaps you could rig a relationship where the accountname is stored or calculated. And where the found set is represented by a relation based on the account name. Thus prividing you with a log-in without the search steps and a stable set of records (through the relation) for the user. Ursus "jbrejcha" <jbrej... (AT) gmail (DOT) com> schreef in berichtnews:1170934348.290016.208220 (AT) a75g2000cwd (DOT) googlegroups.com... Hello, I'm using a startup script, that shows just the records based on creator, copied from get(accountname): If [ Get(PrivilegeSetName)="Set" ] Show/Hide Status Area [ Lock; Hide ] Go to Layout [ "Main" (DB) ] If [ Get(AccountName)="user1" ] Enter Find Mode [ ] Set Field [ DB::user_ID; Get(AccountName) ] Perform Find [ ] Else If [ Get(AccountName)="user2" ] Enter Find Mode [ ] Set Field [ DB::user_ID; Get(AccountName) ] Perform Find [ ] End If End If However, this works with one user only (regardless of its position in the script), and any other user with the same privilege set isn't recognised after login thru IWP - meaning it cannot create new records, calculations aren't auto-inserted, etc. Sometimes even the file serving the database has to be reopened for all the changes (in privileges, scripts, etc) to propagate. Has anyone solved such issues? Using FM Pro 8 on Mac. Thank you. |
that's why the use of Else If.
I'm trying getting the found set through a relation with the
AccountName, which seems really a more straightforward and secure
approach. However, while it works for displaying records related to
the Accountname, I have to create a portal in order to add new
records. Without portals I just keep getting the same data in every
new record I make. Any ideas on how to use the relations properly? In
the current setup the Find is only locked-off with the Status area.
Btw, the tables in use are: DB, DB-parts, DB-work. Each record in DB
displays one portal for related "parts" and one for related "work".
Jan
#2
| |||
| |||
|
|
On Feb 8, 2:10 pm, "Ursus" <ursus.k... (AT) wanadoo (DOT) nl> wrote: Do you have more users then User1 and User2? If not then try to replace the Else If with an Else. I see what you are doing and have a question. The user gets presented with a found set, based on his/her AccountName. Is this failsafe for you? Is there no way the user can change this found set along the way? I don't know how your tables are set up, and don't know if it might be practicle, but perhaps you could rig a relationship where the accountname is stored or calculated. And where the found set is represented by a relation based on the account name. Thus prividing you with a log-in without the search steps and a stable set of records (through the relation) for the user. Ursus "jbrejcha" <jbrej... (AT) gmail (DOT) com> schreef in berichtnews:1170934348.290016.208220 (AT) a75g2000cwd (DOT) googlegroups.com... Hello, I'm using a startup script, that shows just the records based on creator, copied from get(accountname): If [ Get(PrivilegeSetName)="Set" ] Show/Hide Status Area [ Lock; Hide ] Go to Layout [ "Main" (DB) ] If [ Get(AccountName)="user1" ] Enter Find Mode [ ] Set Field [ DB::user_ID; Get(AccountName) ] Perform Find [ ] Else If [ Get(AccountName)="user2" ] Enter Find Mode [ ] Set Field [ DB::user_ID; Get(AccountName) ] Perform Find [ ] End If End If However, this works with one user only (regardless of its position in the script), and any other user with the same privilege set isn't recognised after login thru IWP - meaning it cannot create new records, calculations aren't auto-inserted, etc. Sometimes even the file serving the database has to be reopened for all the changes (in privileges, scripts, etc) to propagate. Has anyone solved such issues? Using FM Pro 8 on Mac. Thank you. Thank you for your suggestions! I'm planning adding more users, so that's why the use of Else If. I'm trying getting the found set through a relation with the AccountName, which seems really a more straightforward and secure approach. However, while it works for displaying records related to the Accountname, I have to create a portal in order to add new records. Without portals I just keep getting the same data in every new record I make. Any ideas on how to use the relations properly? In the current setup the Find is only locked-off with the Status area. Btw, the tables in use are: DB, DB-parts, DB-work. Each record in DB displays one portal for related "parts" and one for related "work". Jan |
#3
| |||
| |||
|
|
Jan, There are more ways to use and add a record through a relation. For instance: Create a script Set variable $RelTemp <Current Table::Relation ID Goto layout <Related table layout Create new record Set Relation ID <$RelTemp Then let the user enter all the items needed en click on a button <Go Back>, which switches back to the original layout and table After setting this up it is simply going to related record <Current found set Or keeping in the main layout showing the fields from the related table. this would leave the other users fields empty and the current user can't change them. Then omit all the records with no valid relation and you are left with the current users found set. A bit more complicated way is using a join table. TableA , TableB, TableA_B Where you have a many to many relation. Linking many existing items of A to many existing items of B. Like an inventory of books. You have many books (TableA) which are on a shelf (TableB) in a library (TableA_B) Since this is set up using TableA_ID and a TableB_ID, you can make it such that a book in tableA always is on one shelf only (TableB), so there allways exists only one combination betwee A and B. This is more complicated to explain step by step, but if you need something like this I will try to explain. Ursus "jbrejcha" <jbrej... (AT) gmail (DOT) com> schreef in berichtnews:1171218177.216217.129950 (AT) j27g2000cwj (DOT) googlegroups.com... On Feb 8, 2:10 pm, "Ursus" <ursus.k... (AT) wanadoo (DOT) nl> wrote: Do you have more users then User1 and User2? If not then try to replace the Else If with an Else. I see what you are doing and have a question. The user gets presented with a found set, based on his/her AccountName. Is this failsafe for you? Is there no way the user can change this found set along the way? I don't know how your tables are set up, and don't know if it might be practicle, but perhaps you could rig a relationship where the accountname is stored or calculated. And where the found set is represented by a relation based on the account name. Thus prividing you with a log-in without the search steps and a stable set of records (through the relation) for the user. Ursus "jbrejcha" <jbrej... (AT) gmail (DOT) com> schreef in berichtnews:1170934348.290016.208220 (AT) a75g2000cwd (DOT) googlegroups.com... Hello, I'm using a startup script, that shows just the records based on creator, copied from get(accountname): If [ Get(PrivilegeSetName)="Set" ] Show/Hide Status Area [ Lock; Hide ] Go to Layout [ "Main" (DB) ] If [ Get(AccountName)="user1" ] Enter Find Mode [ ] Set Field [ DB::user_ID; Get(AccountName) ] Perform Find [ ] Else If [ Get(AccountName)="user2" ] Enter Find Mode [ ] Set Field [ DB::user_ID; Get(AccountName) ] Perform Find [ ] End If End If However, this works with one user only (regardless of its position in the script), and any other user with the same privilege set isn't recognised after login thru IWP - meaning it cannot create new records, calculations aren't auto-inserted, etc. Sometimes even the file serving the database has to be reopened for all the changes (in privileges, scripts, etc) to propagate. Has anyone solved such issues? Using FM Pro 8 on Mac. Thank you. Thank you for your suggestions! I'm planning adding more users, so that's why the use of Else If. I'm trying getting the found set through a relation with the AccountName, which seems really a more straightforward and secure approach. However, while it works for displaying records related to the Accountname, I have to create a portal in order to add new records. Without portals I just keep getting the same data in every new record I make. Any ideas on how to use the relations properly? In the current setup the Find is only locked-off with the Status area. Btw, the tables in use are: DB, DB-parts, DB-work. Each record in DB displays one portal for related "parts" and one for related "work". Jan |
1) startup script:
If [ Get(PrivilegeSetName)="Set" ]
Show/Hide Status Area
[ Lock; Hide ]
Go to Layout [ "Main" (DB) ]
End If
-- When logging in with an account with the SET privilege, the status
area doesn't hide, though the script shows the Main layout... Any
ideas for correcting this behavior?
2) Main layout:
Here is a portal to the DB table based on a relationship from
get(accountname) and userID showing only the user records. In the
portal row there is a GTTR button opening the full record (meaning a
layout showing each field from DB, as well as portals to related DB-
parts and DB-work.)
-- There is a problem with the portal, as it does show correctly the
related records, but the portal row is inaccessible, neither one can
click on the GTTR button. Strangely enough this happens only in IWP,
on the desktop it works correctly. The IWP privileges enable the users
to access the related layouts and records...
Thanks for your ideas!
Jan
#4
| |||
| |||
|
|
On Feb 11, 8:25 pm, "Ursus" <ursus.k... (AT) wanadoo (DOT) nl> wrote: Jan, There are more ways to use and add a record through a relation. For instance: Create a script Setvariable $RelTemp <Current Table::Relation ID Goto layout <Related table layout Create new record SetRelation ID <$RelTemp Then let the user enter all the items needed en click on a button <Go Back>, which switches back to the original layout and table After setting this up it is simply going to related record <Current found set Or keeping in the main layout showing the fields from the related table. this would leave the other users fields empty and the current user can't change them. Then omit all the records with no valid relation and you are left with the current users foundset. A bit more complicated way is using a join table. TableA , TableB, TableA_B Where you have a many to many relation. Linking many existing items of A to many existing items of B. Like an inventory of books. You have many books (TableA) which are on a shelf (TableB) in a library (TableA_B) Since this issetup using TableA_ID and a TableB_ID, you can make it such that a book in tableA always is on one shelf only (TableB), so there allways exists only one combination betwee A and B. This is more complicated to explain step by step, but if you need something like this I will try to explain. Ursus "jbrejcha" <jbrej... (AT) gmail (DOT) com> schreef in berichtnews:1171218177.216217.129950 (AT) j27g2000cwj (DOT) googlegroups.com... On Feb 8, 2:10 pm, "Ursus" <ursus.k... (AT) wanadoo (DOT) nl> wrote: Do you have more users then User1 and User2? If not then try to replace the Else If with an Else. I see what you are doing and have a question. The user gets presented with a foundset, based on his/her AccountName. Is this failsafe for you? Is there no way the user can change this foundsetalong the way? I don't know how your tables aresetup, and don't know if it might be practicle, but perhaps you could rig a relationship where the accountname is stored or calculated. And where the foundsetis represented by a relation based on the account name. Thus prividing you with a log-in without the search steps and a stable setof records (through the relation) for the user. Ursus "jbrejcha" <jbrej... (AT) gmail (DOT) com> schreef in berichtnews:1170934348.290016.208220 (AT) a75g2000cwd (DOT) googlegroups.com... Hello, I'm using a startup script, that shows just the records based on creator, copied from get(accountname): If [ Get(PrivilegeSetName)="Set" ] Show/Hide Status Area [ Lock; Hide ] Go to Layout [ "Main" (DB) ] If [ Get(AccountName)="user1" ] Enter Find Mode [ ] SetField [ DB::user_ID; Get(AccountName) ] Perform Find [ ] Else If [ Get(AccountName)="user2" ] Enter Find Mode [ ] SetField [ DB::user_ID; Get(AccountName) ] Perform Find [ ] End If End If However, this works with one user only (regardless of its position in the script), and any other user with the sameprivilegesetisn't recognised after login thru IWP - meaning it cannot create new records, calculations aren't auto-inserted, etc. Sometimes even the file serving the database has to be reopened for all the changes (in privileges, scripts, etc) to propagate. Has anyone solved such issues? Using FM Pro 8 on Mac. Thank you. Thank you for your suggestions! I'm planning adding more users, so that's why the use of Else If. I'm trying getting the foundsetthrough a relation with the AccountName, which seems really a more straightforward and secure approach. However, while it works for displaying records related to the Accountname, I have to create a portal in order to add new records. Without portals I just keep getting the same data in every new record I make. Any ideas on how to use the relations properly? In the current setup the Find is only locked-off with the Status area. Btw, the tables in use are: DB, DB-parts, DB-work. Each record in DB displays one portal for related "parts" and one for related "work". Jan What I have now is the following: 1) startup script: If [ Get(PrivilegeSetName)="Set" ] Show/Hide Status Area [ Lock; Hide ] Go to Layout [ "Main" (DB) ] End If -- When logging in with an account with theSETprivilege, the status area doesn't hide, though the script shows the Main layout... Any ideas for correcting this behavior? 2) Main layout: Here is a portal to the DB table based on a relationship from get(accountname) and userID showing only the user records. In the portal row there is a GTTR button opening the full record (meaning a layout showing each field from DB, as well as portals to related DB- parts and DB-work.) -- There is a problem with the portal, as it does show correctly the related records, but the portal row is inaccessible, neither one can click on the GTTR button. Strangely enough this happens only in IWP, on the desktop it works correctly. The IWP privileges enable the users to access the related layouts and records... Thanks for your ideas! Jan |
Thanks, Jan
#5
| |||
| |||
|
|
On Feb 11, 8:25 pm, "Ursus" <ursus.k... (AT) wanadoo (DOT) nl> wrote: Jan, There are more ways to use and add a record through a relation. For instance: Create a script Setvariable $RelTemp <Current Table::Relation ID Goto layout <Related table layout Create new record SetRelation ID <$RelTemp Then let the user enter all the items needed en click on a button <Go Back>, which switches back to the original layout and table After setting this up it is simply going to related record <Current found set Or keeping in the main layout showing the fields from the related table. this would leave the other users fields empty and the current user can't change them. Then omit all the records with no valid relation and you are left with the current users foundset. A bit more complicated way is using a join table. TableA , TableB, TableA_B Where you have a many to many relation. Linking many existing items of A to many existing items of B. Like an inventory of books. You have many books (TableA) which are on a shelf (TableB) in a library (TableA_B) Since this issetup using TableA_ID and a TableB_ID, you can make it such that a book in tableA always is on one shelf only (TableB), so there allways exists only one combination betwee A and B. This is more complicated to explain step by step, but if you need something like this I will try to explain. Ursus "jbrejcha" <jbrej... (AT) gmail (DOT) com> schreef in berichtnews:1171218177.216217.129950 (AT) j27g2000cwj (DOT) googlegroups.com... On Feb 8, 2:10 pm, "Ursus" <ursus.k... (AT) wanadoo (DOT) nl> wrote: Do you have more users then User1 and User2? If not then try to replace the Else If with an Else. I see what you are doing and have a question. The user gets presented with a foundset, based on his/her AccountName. Is this failsafe for you? Is there no way the user can change this foundsetalong the way? I don't know how your tables aresetup, and don't know if it might be practicle, but perhaps you could rig a relationship where the accountname is stored or calculated. And where the foundsetis represented by a relation based on the account name. Thus prividing you with a log-in without the search steps and a stable setof records (through the relation) for the user. Ursus "jbrejcha" <jbrej... (AT) gmail (DOT) com> schreef in berichtnews:1170934348.290016.208220 (AT) a75g2000cwd (DOT) googlegroups.com... Hello, I'm using a startup script, that shows just the records based on creator, copied from get(accountname): If [ Get(PrivilegeSetName)="Set" ] Show/Hide Status Area [ Lock; Hide ] Go to Layout [ "Main" (DB) ] If [ Get(AccountName)="user1" ] Enter Find Mode [ ] SetField [ DB::user_ID; Get(AccountName) ] Perform Find [ ] Else If [ Get(AccountName)="user2" ] Enter Find Mode [ ] SetField [ DB::user_ID; Get(AccountName) ] Perform Find [ ] End If End If However, this works with one user only (regardless of its position in the script), and any other user with the sameprivilegesetisn't recognised after login thru IWP - meaning it cannot create new records, calculations aren't auto-inserted, etc. Sometimes even the file serving the database has to be reopened for all the changes (in privileges, scripts, etc) to propagate. Has anyone solved such issues? Using FM Pro 8 on Mac. Thank you. Thank you for your suggestions! I'm planning adding more users, so that's why the use of Else If. I'm trying getting the foundsetthrough a relation with the AccountName, which seems really a more straightforward and secure approach. However, while it works for displaying records related to the Accountname, I have to create a portal in order to add new records. Without portals I just keep getting the same data in every new record I make. Any ideas on how to use the relations properly? In the current setup the Find is only locked-off with the Status area. Btw, the tables in use are: DB, DB-parts, DB-work. Each record in DB displays one portal for related "parts" and one for related "work". Jan What I have now is the following: 1) startup script: If [ Get(PrivilegeSetName)="Set" ] Show/Hide Status Area [ Lock; Hide ] Go to Layout [ "Main" (DB) ] End If -- When logging in with an account with theSETprivilege, the status area doesn't hide, though the script shows the Main layout... Any ideas for correcting this behavior? 2) Main layout: Here is a portal to the DB table based on a relationship from get(accountname) and userID showing only the user records. In the portal row there is a GTTR button opening the full record (meaning a layout showing each field from DB, as well as portals to related DB- parts and DB-work.) -- There is a problem with the portal, as it does show correctly the related records, but the portal row is inaccessible, neither one can click on the GTTR button. Strangely enough this happens only in IWP, on the desktop it works correctly. The IWP privileges enable the users to access the related layouts and records... Thanks for your ideas! Jan |
Thanks, Jan
#6
| |||
| |||
|
|
On Feb 12, 4:52 pm, "jbrejcha" <jbrej... (AT) gmail (DOT) com> wrote: On Feb 11, 8:25 pm, "Ursus" <ursus.k... (AT) wanadoo (DOT) nl> wrote: Jan, There are more ways to use and add a record through a relation. For instance: Create a script Setvariable $RelTemp <Current Table::Relation ID Goto layout <Related table layout Create new record SetRelation ID <$RelTemp Then let the user enter all the items needed en click on a button <Go Back>, which switches back to the original layout and table After setting this up it is simply going to related record <Current found set Or keeping in the main layout showing the fields from the related table. this would leave the other users fields empty and the current user can't change them. Then omit all the records with no valid relation and you are left with the current users foundset. A bit more complicated way is using a join table. TableA , TableB, TableA_B Where you have a many to many relation. Linking many existing items of A to many existing items of B. Like an inventory of books. You have many books (TableA) which are on a shelf (TableB) in a library (TableA_B) Since this issetup using TableA_ID and a TableB_ID, you can make it such that a book in tableA always is on one shelf only (TableB), so there allways exists only one combination betwee A and B. This is more complicated to explain step by step, but if you need something like this I will try to explain. Ursus "jbrejcha" <jbrej... (AT) gmail (DOT) com> schreef in berichtnews:1171218177.216217.129950 (AT) j27g2000cwj (DOT) googlegroups.com... On Feb 8, 2:10 pm, "Ursus" <ursus.k... (AT) wanadoo (DOT) nl> wrote: Do you have more users then User1 and User2? If not then try to replace the Else If with an Else. I see what you are doing and have a question. The user gets presented with a foundset, based on his/her AccountName. Is this failsafe for you? Is there no way the user can change this foundsetalong the way? I don't know how your tables aresetup, and don't know if it might be practicle, but perhaps you could rig a relationship where the accountname is stored or calculated. And where the foundsetis represented by a relation based on the account name. Thus prividing you with a log-in without the search steps and a stable setof records (through the relation) for the user. Ursus "jbrejcha" <jbrej... (AT) gmail (DOT) com> schreef in berichtnews:1170934348.290016.208220 (AT) a75g2000cwd (DOT) googlegroups.com... Hello, I'm using a startup script, that shows just the records based on creator, copied from get(accountname): If [ Get(PrivilegeSetName)="Set" ] Show/Hide Status Area [ Lock; Hide ] Go to Layout [ "Main" (DB) ] If [ Get(AccountName)="user1" ] Enter Find Mode [ ] SetField [ DB::user_ID; Get(AccountName) ] Perform Find [ ] Else If [ Get(AccountName)="user2" ] Enter Find Mode [ ] SetField [ DB::user_ID; Get(AccountName) ] Perform Find [ ] End If End If However, this works with one user only (regardless of its position in the script), and any other user with the sameprivilegesetisn't recognised after login thru IWP - meaning it cannot create new records, calculations aren't auto-inserted, etc. Sometimes even the file serving the database has to be reopened for all the changes (in privileges, scripts, etc) to propagate. Has anyone solved such issues? Using FM Pro 8 on Mac. Thank you. Thank you for your suggestions! I'm planning adding more users, so that's why the use of Else If. I'm trying getting the foundsetthrough a relation with the AccountName, which seems really a more straightforward and secure approach. However, while it works for displaying records related to the Accountname, I have to create a portal in order to add new records. Without portals I just keep getting the same data in every new record I make. Any ideas on how to use the relations properly? In the current setup the Find is only locked-off with the Status area. Btw, the tables in use are: DB, DB-parts, DB-work. Each record in DB displays one portal for related "parts" and one for related "work". Jan What I have now is the following: 1) startup script: If [ Get(PrivilegeSetName)="Set" ] Show/Hide Status Area [ Lock; Hide ] Go to Layout [ "Main" (DB) ] End If -- When logging in with an account with theSETprivilege, the status area doesn't hide, though the script shows the Main layout... Any ideas for correcting this behavior? 2) Main layout: Here is a portal to the DB table based on a relationship from get(accountname) and userID showing only the user records. In the portal row there is a GTTR button opening the full record (meaning a layout showing each field from DB, as well as portals to related DB- parts and DB-work.) -- There is a problem with the portal, as it does show correctly the related records, but the portal row is inaccessible, neither one can click on the GTTR button. Strangely enough this happens only in IWP, on the desktop it works correctly. The IWP privileges enable the users to access the related layouts and records... Thanks for your ideas! Jan Any ideas on how to troubleshoot these issues? Thanks, Jan |
and footer. The portal was in the body part, but reached with its
border into the header. After putting the portal all in the body
section, the issue disappeared.
As I noticed elsewhere, the part dividers are very likely to cause
troubles in IWP where there's not some white space around them.
Many thanks! Jan
#7
| |||
| |||
|
|
On Feb 12, 4:52 pm, "jbrejcha" <jbrej... (AT) gmail (DOT) com> wrote: On Feb 11, 8:25 pm, "Ursus" <ursus.k... (AT) wanadoo (DOT) nl> wrote: Jan, There are more ways to use and add a record through a relation. For instance: Create a script Setvariable $RelTemp <Current Table::Relation ID Goto layout <Related table layout Create new record SetRelation ID <$RelTemp Then let the user enter all the items needed en click on a button <Go Back>, which switches back to the original layout and table After setting this up it is simply going to related record <Current found set Or keeping in the main layout showing the fields from the related table. this would leave the other users fields empty and the current user can't change them. Then omit all the records with no valid relation and you are left with the current users foundset. A bit more complicated way is using a join table. TableA , TableB, TableA_B Where you have a many to many relation. Linking many existing items of A to many existing items of B. Like an inventory of books. You have many books (TableA) which are on a shelf (TableB) in a library (TableA_B) Since this issetup using TableA_ID and a TableB_ID, you can make it such that a book in tableA always is on one shelf only (TableB), so there allways exists only one combination betwee A and B. This is more complicated to explain step by step, but if you need something like this I will try to explain. Ursus "jbrejcha" <jbrej... (AT) gmail (DOT) com> schreef in berichtnews:1171218177.216217.129950 (AT) j27g2000cwj (DOT) googlegroups.com... On Feb 8, 2:10 pm, "Ursus" <ursus.k... (AT) wanadoo (DOT) nl> wrote: Do you have more users then User1 and User2? If not then try to replace the Else If with an Else. I see what you are doing and have a question. The user gets presented with a foundset, based on his/her AccountName. Is this failsafe for you? Is there no way the user can change this foundsetalong the way? I don't know how your tables aresetup, and don't know if it might be practicle, but perhaps you could rig a relationship where the accountname is stored or calculated. And where the foundsetis represented by a relation based on the account name. Thus prividing you with a log-in without the search steps and a stable setof records (through the relation) for the user. Ursus "jbrejcha" <jbrej... (AT) gmail (DOT) com> schreef in berichtnews:1170934348.290016.208220 (AT) a75g2000cwd (DOT) googlegroups.com... Hello, I'm using a startup script, that shows just the records based on creator, copied from get(accountname): If [ Get(PrivilegeSetName)="Set" ] Show/Hide Status Area [ Lock; Hide ] Go to Layout [ "Main" (DB) ] If [ Get(AccountName)="user1" ] Enter Find Mode [ ] SetField [ DB::user_ID; Get(AccountName) ] Perform Find [ ] Else If [ Get(AccountName)="user2" ] Enter Find Mode [ ] SetField [ DB::user_ID; Get(AccountName) ] Perform Find [ ] End If End If However, this works with one user only (regardless of its position in the script), and any other user with the sameprivilegesetisn't recognised after login thru IWP - meaning it cannot create new records, calculations aren't auto-inserted, etc. Sometimes even the file serving the database has to be reopened for all the changes (in privileges, scripts, etc) to propagate. Has anyone solved such issues? Using FM Pro 8 on Mac. Thank you. Thank you for your suggestions! I'm planning adding more users, so that's why the use of Else If. I'm trying getting the foundsetthrough a relation with the AccountName, which seems really a more straightforward and secure approach. However, while it works for displaying records related to the Accountname, I have to create a portal in order to add new records. Without portals I just keep getting the same data in every new record I make. Any ideas on how to use the relations properly? In the current setup the Find is only locked-off with the Status area. Btw, the tables in use are: DB, DB-parts, DB-work. Each record in DB displays one portal for related "parts" and one for related "work". Jan What I have now is the following: 1) startup script: If [ Get(PrivilegeSetName)="Set" ] Show/Hide Status Area [ Lock; Hide ] Go to Layout [ "Main" (DB) ] End If -- When logging in with an account with theSETprivilege, the status area doesn't hide, though the script shows the Main layout... Any ideas for correcting this behavior? 2) Main layout: Here is a portal to the DB table based on a relationship from get(accountname) and userID showing only the user records. In the portal row there is a GTTR button opening the full record (meaning a layout showing each field from DB, as well as portals to related DB- parts and DB-work.) -- There is a problem with the portal, as it does show correctly the related records, but the portal row is inaccessible, neither one can click on the GTTR button. Strangely enough this happens only in IWP, on the desktop it works correctly. The IWP privileges enable the users to access the related layouts and records... Thanks for your ideas! Jan |
caused the malfunction in IWP.
What I noticed elsewhere when using layout parts in IWP is, that there
must be some white space around them in order to display - and work -
correctly.
Many thanks, Jan
#8
| |||
| |||
|
|
On Feb 12, 4:52 pm, "jbrejcha" <jbrej... (AT) gmail (DOT) com> wrote: On Feb 11, 8:25 pm, "Ursus" <ursus.k... (AT) wanadoo (DOT) nl> wrote: Jan, There are more ways to use and add a record through a relation. For instance: Create a script Setvariable $RelTemp <Current Table::Relation ID Goto layout <Related table layout Create new record SetRelation ID <$RelTemp Then let the user enter all the items needed en click on a button <Go Back>, which switches back to the original layout and table After setting this up it is simply going to related record <Current found set Or keeping in the main layout showing the fields from the related table. this would leave the other users fields empty and the current user can't change them. Then omit all the records with no valid relation and you are left with the current users foundset. A bit more complicated way is using a join table. TableA , TableB, TableA_B Where you have a many to many relation. Linking many existing items of A to many existing items of B. Like an inventory of books. You have many books (TableA) which are on a shelf (TableB) in a library (TableA_B) Since this issetup using TableA_ID and a TableB_ID, you can make it such that a book in tableA always is on one shelf only (TableB), so there allways exists only one combination betwee A and B. This is more complicated to explain step by step, but if you need something like this I will try to explain. Ursus "jbrejcha" <jbrej... (AT) gmail (DOT) com> schreef in berichtnews:1171218177.216217.129950 (AT) j27g2000cwj (DOT) googlegroups.com... On Feb 8, 2:10 pm, "Ursus" <ursus.k... (AT) wanadoo (DOT) nl> wrote: Do you have more users then User1 and User2? If not then try to replace the Else If with an Else. I see what you are doing and have a question. The user gets presented with a foundset, based on his/her AccountName. Is this failsafe for you? Is there no way the user can change this foundsetalong the way? I don't know how your tables aresetup, and don't know if it might be practicle, but perhaps you could rig a relationship where the accountname is stored or calculated. And where the foundsetis represented by a relation based on the account name. Thus prividing you with a log-in without the search steps and a stable setof records (through the relation) for the user. Ursus "jbrejcha" <jbrej... (AT) gmail (DOT) com> schreef in berichtnews:1170934348.290016.208220 (AT) a75g2000cwd (DOT) googlegroups.com... Hello, I'm using a startup script, that shows just the records based on creator, copied from get(accountname): If [ Get(PrivilegeSetName)="Set" ] Show/Hide Status Area [ Lock; Hide ] Go to Layout [ "Main" (DB) ] If [ Get(AccountName)="user1" ] Enter Find Mode [ ] SetField [ DB::user_ID; Get(AccountName) ] Perform Find [ ] Else If [ Get(AccountName)="user2" ] Enter Find Mode [ ] SetField [ DB::user_ID; Get(AccountName) ] Perform Find [ ] End If End If However, this works with one user only (regardless of its position in the script), and any other user with the sameprivilegesetisn't recognised after login thru IWP - meaning it cannot create new records, calculations aren't auto-inserted, etc. Sometimes even the file serving the database has to be reopened for all the changes (in privileges, scripts, etc) to propagate. Has anyone solved such issues? Using FM Pro 8 on Mac. Thank you. Thank you for your suggestions! I'm planning adding more users, so that's why the use of Else If. I'm trying getting the foundsetthrough a relation with the AccountName, which seems really a more straightforward and secure approach. However, while it works for displaying records related to the Accountname, I have to create a portal in order to add new records. Without portals I just keep getting the same data in every new record I make. Any ideas on how to use the relations properly? In the current setup the Find is only locked-off with the Status area. Btw, the tables in use are: DB, DB-parts, DB-work. Each record in DB displays one portal for related "parts" and one for related "work". Jan What I have now is the following: 1) startup script: If [ Get(PrivilegeSetName)="Set" ] Show/Hide Status Area [ Lock; Hide ] Go to Layout [ "Main" (DB) ] End If -- When logging in with an account with theSETprivilege, the status area doesn't hide, though the script shows the Main layout... Any ideas for correcting this behavior? 2) Main layout: Here is a portal to the DB table based on a relationship from get(accountname) and userID showing only the user records. In the portal row there is a GTTR button opening the full record (meaning a layout showing each field from DB, as well as portals to related DB- parts and DB-work.) -- There is a problem with the portal, as it does show correctly the related records, but the portal row is inaccessible, neither one can click on the GTTR button. Strangely enough this happens only in IWP, on the desktop it works correctly. The IWP privileges enable the users to access the related layouts and records... Thanks for your ideas! Jan |
caused the malfunction in IWP.
What I noticed elsewhere when using layout parts in IWP is, that there
must be some white space around them in order to display - and work -
correctly.
Many thanks, Jan
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.