I need help locating a specific value within an array. I’ve got an array I’m loading like this: IF “Inventory Post Group”.FIND(’-’) THEN REPEAT INDEX := INDEX + 1; IPGArray[INDEX] := FORMAT(“Inventory Post Group”.Code); UNTIL “Inventory Post Group”.NEXT = 0; The array loads the code for each group successfully. Each of my items has one of the codes on it. What I want to be able to do is then find the element of the array matching the item I’m reading from the item table. Is there a way to look up a value in an array? Pretty Please![:)]
Unless there is a specific reason for using an array, I would recommend using a temporary table instead. You can use this table just as a real one, except that nothing is written/modified/deleted in the database. All the filter and find operations will work just fine.
That would be great if I could create a temporary table that had just two fields: Inventory Product Code, and Sales ($). But from what I’ve read on the Temporary table, it has to have a subtype of another table. I don’t know which table to pick. Is there a way to create one and specify the fields as well - not picking a Navision table as the subtype? I’m a newby…so excuse me if it’s a dumb question.
Just choose a table with a code and a decimal field as subtype for your “MyTable”. Table 13 would be fine, it has only three fields. Make sure you set the property “Temporary” to TRUE. Then populate the records with MyTable.init; MyTable.Code := ‘XXXX’; MyTable.“Commission %” := 999.999; MyTable.insert; and so on. Good luck! Pelle
What bothers me about this is someone else seeing I’m using SalesPerson/Buyer table and wondering what the heck I was thinking. I do like the idea of using a temp table so I can use the GET and FIND functions - that’s exactly what I’m after. SO…[8D]…I’m creating a temporary table with all my various field types - code, integer, decimal, text - and creating a key on each. I can then use this table named “Generic Temporary Table” and everyone will know exactly what I’m doing. So, what do you think? Good idea, or bad idea? I know I’ll burn one of my $$tables$$, but I’m willing to live with that to reduce complexity.
Hi Faithie
quote:
Originally posted by faithiejlewis
… I do like the idea of using a temp table so I can use the GET and FIND functions - that’s exactly what I’m after. SO…[8D]…I’m creating a temporary table with all my various field types - code, integer, decimal, text - and creating a key on each. I can then use this table named “Generic Temporary Table” and everyone will know exactly what I’m doing. So, what do you think? Good idea, or bad idea? I know I’ll burn one of my $$tables$$, but I’m willing to live with that to reduce complexity.
This exactly is the way how I work. I use a table called ‘Temp. Buffer’ to store and hold variables in a lot of codeunits and forms. You have to take care to put all data you need to the table and delete it at the end of your code. My primary key is No(Integer),UserID(Code),WorkingCode(Code). So each user can store his own temporary data in this table. bye André (just back from the club [8D])
Hi. My name is Faithie, and I’m a Navisionholic…[:D][:p][:(][xx(][;)]…(now at home, but can’t seem to live without it!)
quote:
My primary key is No(Integer),UserID(Code),WorkingCode(Code). So each user can store his own temporary data in this table.
One question Andre - if I just use my “Generic Temp Table” as a subtype on a temporary table, do I have to worry about multiple users accessing it? I guess I’m confused… I thought it being a temp table made it available (and it’s data) to only that session and program. Is there a performance reason or something for letting them actually write to the table?
Hi Faithie, First thing you need to know is that temporary tables are stored on the client computer and is attached to every session so there is no danger from multiple users as long as you keep it temporary [;)] Also there is a speed advantage with it because it is stored in the client’s RAM so therefore it is a lot faster than access to db. Downside to that is that if you have a lot of data to put in it it eats up a lot of RAM [xx(] Also one thing that I found out recently is that as long as you use a table just as temporary and never actually insert data in it the client’s license does not need to have permissions to it. So you could create 100 tables that fit your needs rather than use the standard ones and the client will not pay for any of them. The obvious advantage is that you can create table that match exactly your needs and have the right names and all. But there is an added bonus to doing that: I am sure everybody has at least once tried to use a standard table as temporary (say sales line) and forgot to set the propert to yes. And what is the first thing you write with temporary tables? reset and then deleteall [B)] Or worse someone else tries to copy the code you did with that but does not copy the variable and creates it manually. [}:)] Just thought you may want to know that.[;)] Cristi
quote:
Originally posted by faithiejlewis
That would be great if I could create a temporary table that had just two fields: Inventory Product Code, and Sales ($).
You could just use the original table (“Inventory Post Group”?). You are not obliged to transfer all fields from the real record to the temporary one - simply copy only the fields you need. Of course, the primary key must be filled in completely. If you need any additional fields or keys you will have to create a new table, though. As Cristi said: Watch out for that property! Each time I code a RESET followed by a DELETEALL on a table that is supposed to be temporary, I double-check the property [B)]. I have also made it a habit to name temporary records in the form “tmpXXXX” [;)]
Hi Just a question: Is the data in a temporary table still there after a ClearAll? This one of the reasons why I use a real table. bye André
Heinz, --------------------------------------------------------------------- Quote: “You could just use the original table (“Inventory Post Group”?). You are not obliged to transfer all fields from the real record to the temporary one …” --------------------------------------------------------------------- Surely though, it is good practice to use temporary tables instead of the real tables - performance issues can be avoided by locking the table from other users? [?]
Andre, a CLEAR or CLEARALL will, AFAIK, not delete any data from the temporary table. As a temporary table works and behaves just like a real one, except that the data is not stored on the server, a CLEAR will clear the record variable used to access the table, but not the table contents itself. We should verify this statement experimentally, though [;)] Connull, with respect to performance, using a temporary table is surely preferrable - I’m not sure about concurrent user access, though. Let’s say you write some temporary data to a real table during the execution of a report. This data is not committed to the database and therefore not visible to other users until the entire transaction is committed. So, all you need to do is a DELETEALL on the “temporary real” table just before your transaction ends. Problems may arise when the table is not initially empty, though. In general, I’d say “it depends”… [:D]
Okay, guys and gals - here’s what I ended up with. I created my Generic Temp Table - code fields, decimal fields, date fields, text fields - I’ll use it a lot! I added it as a temporary table, and before each group of records I want to write (then export, then write again) I did an INIT. Then as I write out my totals, I did a GET - retrieved the record, and did a MODIFY to update the totals. It works VERY WELL and I don’t see any performance difference than the report without it. So, I’m sold on using it for this kind of situation. Thanks for all your help(S). [:D]
Well there goes another happy customer [:D] Wish it was this easy with clients too [;)] Cristi