3 Replies Latest reply on Aug 24, 2014 5:25 AM by erolst

    Question about matching in portals ?

    bartprins

      Hi there,

       

      Don't really know what kind of title is should have given this question

      But i have the following question, i've made an example database which perhaps makes it more visual.

       

      I have a couple of tables; Clients, Maximum and Production. Per client i will recievce a maximum ammount of production i can charge to a client. This data is received from a third party.

      I've made a layout where all three tables are visible so i can see directly while adding production whether this exceeds the ammount of maximum billable production.

       

      I would like to have a popup, or conditional formatting or something else which makes it visible for me wheter i exceed the maximum for that product and by how much it exceeds.

       

      However by working with two portals i don't have a clue how to script this.

       

      Any help is appreciated ! Thank you reading !

       

      Much oblidged

       

       

      Bart Prins

        • 1. Re: Question about matching in portals ?
          erolst

          Hi Bart -

           

          1. Please don't confuse yourself (and others) by giving a foreign key the name of the primary key.

           

          Case in point: don't connect Clients --< Production by Clients::clientID = Production::productionID. This should be Clients::clientID = Production::clientID. Optionally, tack on an FK, _fk, PK or whatever helps you distinguish those two types of keys (and a foreign key is never set to a serial auto-enter; that's the prerogative of the primary key).

           

          2. Give every table you create an auto-enter primary key.

           

          3. What you want to achieve is basically a question of connecting the right dots (TOs), or creating new ones; see the attached example.

           

          4. While it's nice to display pretty colors, it's even better to prevent creating a negative … well, “stock quantity” in the first place. Reconsider the process by which you create production entries (i.e. script it, don't allow manual creation via portal) and how to handle modifactions of existing production record minutes.

           

          5. In your real solution, you do of course have a table of production types, i.e. “Services” or the like, and use IDs to represent those Services in Production and Maximum –  right?!

           

          6. After these many posts, I just have to break it to you: the word is “obliged”

          • 2. Re: Question about matching in portals ?
            bartprins

            Hi Erolst,

             

            Thank you very much for your reply !!

             

            1 to 4. thanks for the explanation still learning but this is very clear

            5. Yes the production types are in a different table

            6. Hahahahaha great my english is very poor but i'm very obliged !!! (still learning too hahah)

             

            One last question, during the input i don't see the input directly, but when i close the record and reopen it i see that everything works.

            Is there some kind of "afterupdate" so i see the changes in ''realtime'' ? 

             

            Agian thank you !

            • 3. Re: Question about matching in portals ?
              erolst

              Bart Prins wrote:

              my english is very poor

              Not at all! I could show you some users in this forum who obviously don't give a frag if anyone understands their variant of “English”, but I don't want to name names. You have to look for yourself.

              Bart Prins wrote:

              Is there some kind of "afterupdate" so i see the changes in ''realtime'' ?

              You could put an OnObjectSave trigger on the pertinent fields to refresh the display; either use Refresh Window[], or (trick!) set the customer's primaryID to itself.

               

              Note that the latter method is more economical in terms of resources (since it will “refresh” just the relationships/portals that use that field, not the layout as a whole), but may be problematic if you use a timestamp for the purpose of tracking “real” modifications within the customer record proper.