beverly@ai.cs.wisc.edu (Beverly Seavey (-Kung)) (09/11/90)
In one of my triggers I have an SQL statement that refers to a global var: SELECT atom_numb, atom_name INTO poss_atoms.atom_numb, poss_atoms.atom_name FROM atom_lookup WHERE atom_lookup.nucleus = global.curr_nucleus; ****** When the trigger gets triggered I get an error msg saying that curr_nucleus is an invalid column name. Changeing the column name doesn't help. THe value of global.curr_nucleus was set up by a form that called this one. In the SQL*Forms manuals there are no examples of use of global vars in SQL. Is it allowed?
lugnut@sequent.UUCP (Don Bolton) (09/11/90)
In article <11212@spool.cs.wisc.edu> beverly@ai.cs.wisc.edu (Beverly Seavey (-Kung)) writes: > > In one of my triggers I have an SQL statement that refers to a > global var: > > > SELECT atom_numb, atom_name > INTO poss_atoms.atom_numb, poss_atoms.atom_name > FROM atom_lookup > WHERE atom_lookup.nucleus = global.curr_nucleus; > > ****** > > > > When the trigger gets triggered I get an error msg saying that > curr_nucleus is an invalid column name. Changeing the column name > doesn't help. THe value of global.curr_nucleus was set up by > a form that called this one. In the SQL*Forms manuals there are > no examples of use of global vars in SQL. Is it allowed? Been awhile since I've mucked with "O" forms but I used to do similar things quite frequently.. You must do a #COPY on your global.var into a field and then compare *that* field to your data field. I assume you have an event trigger that calls the form that sets your value. add the step to do the #COPY to it. Ie: last step...#COPY global.var :poss_atoms.nondatabasefield (I would use a non database field hidden on page 0) then do your compare to the non database field.. select atom_numb, atom_name into poss_atoms.atom_num, poss_atoms.atom_name from atom_lookup.nucleus where atom_lookup.nucleus = poss_atoms.nondatabasefield As I said it been awhile, used to do TONS of this. I can supply some examples if you get stuck. (Provided I can find them old .inp files :-)) I've been Informixed up of late :-) ********************************************************************* The monitor shows a system floating down a river on a lazy afternoon, My terminal is a picture of a command long forgotten, A sensation of suspense fills the air, Did I forget the command "oracle start your engine"?
rad@genco.uucp (Bob Daniel) (09/11/90)
In article <11212@spool.cs.wisc.edu> beverly@ai.cs.wisc.edu (Beverly Seavey (-Kung)) writes: > > In one of my triggers I have an SQL statement that refers to a > global var: > > > SELECT atom_numb, atom_name > INTO poss_atoms.atom_numb, poss_atoms.atom_name > FROM atom_lookup > WHERE atom_lookup.nucleus = global.curr_nucleus; Are you using Forms 3.0? Did you use a : infront of global? Also, try using the NAME_IN package: (I'm not sure about this but may be worth a try.) WHERE atom_lookup.nucleus = NAME_IN('global.curr_nucleus'); Another method is to have a dummy field in a block and assign the global to the dummy: (This one should work) :block.dummy := :global.curr_nucleus; <select statement> where atom_lookup.nucleus = :block.dummy;
kbittner@oracle.uucp (Kurt Bittner) (09/11/90)
In article <11212@spool.cs.wisc.edu> beverly@ai.cs.wisc.edu (Beverly Seavey (-Kung)) writes: > > In one of my triggers I have an SQL statement that refers to a > global var: > > > SELECT atom_numb, atom_name > INTO poss_atoms.atom_numb, poss_atoms.atom_name > FROM atom_lookup > WHERE atom_lookup.nucleus = global.curr_nucleus; > > ****** > > > > When the trigger gets triggered I get an error msg saying that > curr_nucleus is an invalid column name. Changeing the column name > doesn't help. THe value of global.curr_nucleus was set up by > a form that called this one. In the SQL*Forms manuals there are > no examples of use of global vars in SQL. Is it allowed? You cannot reference global variables in a SQL statement in Forms 2.3; you will have to #COPY the value in the global variable to a hidden field (on Page 0), then reference that field. SQL*Forms 3.0 DOES allow global fields to be referenced in a SQL statement, so for that reason (and many others) you will want to upgrade as soon as Forms 3.0 is available on your machine. Kurt Bittner kbittner@oracle.com Field Technical Rep "My opinions are purely my own and in no way Oracle Corporation represent the official views of my employer."
tprife@venus.lerc.nasa.gov (Mike Rife (Boeing)) (09/19/90)
You can not reference globals in SQL trigger statements. What you want to do is copy the global into a temporary field on page 0 of the form and reference the temporary field.
randall@informix.com (Randall Rhea) (09/25/90)
You CAN reference globals in version 3.0 of SQL*Forms, as long as you
use a PL/SQL trigger. For example:
SELECT cus_name
FROM customers
WHERE cus_id = :GLOBAL.cus_id;
However, you still cannot reference GLOBALs in the default WHERE/ORDER_BY
clause of a block, or in a list-of-values-SQL statement.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Randall Rhea Informix Software, Inc.
Senior Programmer/Analyst, MIS uunet!pyramid!infmx!randall