Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Confusion Adding Records to IMH_TransDataEntryLine

Status
Not open for further replies.

BeejCyr

MIS
Aug 1, 2002
49
US
If there is a MAS90 developer's forum anywhere, please let me know. I know this is more of a MAS90/200 user group.

I am trying to insert records directly into the IMH_TransDataEntryLine table. (Inventory Transaction Entry). Before I can do that, I need to understand how the line numbering works.

From what I can see, the first record (record 0) holds the key to all this. I believe I understand how the LineToPreviousLine field is used, but I do not understand the significance of the other fields on that record. Can someone shed some light on this?

I spent many many years writting these types of applications for Platinum for DOS. I just don't see the need in having what amounts to global line numbers. There should be a unique key for ref#, Trantype, and maybe a sequence number, where the seq # resets for each transaction #. I hope the folks at Best take these ideas from Platinum and put them into MAS90.

Thanks in advance for your help.
 
"The folks at Best" own Platinum. ___________________
Quang Tran
(MCSE, A+)
 
I know. Thats why I am especially hopeful they will take a tip from a product they have complete access to.
 
On a related note....

I decided I was just going to shove a line in there using my best guess (Hey what are test systems for :) ) however.... I am getting an error. The odbc driver comes back and says "Unable to determine files primary key".

[sarcasm mode on] I just love the documentation at the providex site.[sarcasm mode off]

I can find nothing on this error other than a repeat of the error message at the providex site along with its error code. I have a REAL sneaky suspicion that the problem comes from the data dictionary that Best provides.

Is there a work around for this? I believe I have decuced what the numbers are being used for but now... in what seems to be traditional providex/mas90 style, I am unable to insert or update the records.
 

The IMH file is what is known as an "Index" file. Rather than using a key piece of information that is unique to each record, the file uses a simple integer number to reference each record. These files are only used in MAS90 where the order-in-which entry is made is required to be preserved. The index file is a linked-list type of file. Index 0 is used to store vital information about the file and cannot be used for data storage (I'll come back to that in a minute). Here's an example of how the file is used.

IMG would hold header-level information. A field called "Link To First Detail Record" exists in this file. It points to the first detail record in IMH.

A valid IMH record would look like this:

Transaction Type <- note that these two fields make up
Reference Number <- the key to IMG
Link to Previous Line <- =0 if this is the 1st dtl record)
Link to Next Line <- =0 if this is the last detail record)
(rest actual IMH data follows)

The idea behind this concept is something like this:

Transaction #1 is entered in the system w/3 lines..IMH records #1,2,3 are used for these 3 lines.
Pull up transaction #1 and delete line #2. Indexes #1 and #3 still hold valid data.. #2 is put on the &quot;deleted index chain&quot; (bear with me, I'll explain this)
Enter transaction #2 with 3 detail lines. MAS90 will re-use index #2, and then use indexes #4 and #5.

Index 0 is used to keep track of the highest index# used and the next available index on the &quot;deleted index chain&quot;

A deleted index will look like this:

Field 1: Null
Field 2: Index to next index on deleted index chain. If this value is zero, there are no more deleted indexes available.

Index 0 looks like this:
Field 1: Number of records actively used
Field 2: Maximum records in the file
Field 3: Next new index available
Field 4: Last removed index record (deleted chain)

To simplify this mess, you may shortcut messing around with deleted indexes and do the following:
(1) Get Index0, next new index available field
(2) Assign your record the this value
(3) Increment the next new index avail field and store
Index 0

If a previous line exists for this inventory transaction, you will need to:
(1) Assign the &quot;Link to previous line&quot; field for your current record
(2) Edit the previous line's &quot;Link to next line&quot; field to point to your current record

If a previous line does not exist for this inventory transaction, you will need to:
(1) Assign the &quot;Link to First Detail Record&quot; field in IMG to point to your current record.

Hope this makes sense--sorry I kinda rambled..

-Chris
 
Wow! Chris.
Thanks. That was very helpful.
I could see how the values were following the number of records but I didn't know thier exact meanings.

Well with the huge push to get this done, and now the odd behavior of the Providex ODBC driver, I think they are going to knukle under and get Visual Integrator for MAS90.

Thanks for you help
 
Beejcyr,

I to am using providex the same way you are. I have just now reached the problem explained here. I am going to see if I can still solve it using providex. I guess I am a glutton for punishment.

Chris,

If I get this working the way you mentioned in this thread, I will have to move on to the Sales order stuff. I am thinking there is a table (SO6_InvoiceDataEntryDetail maybe) that will have the same issues as IMH_TransDataEntryLine. Will it be the same process to get data into that table as you listed above? Also, I am a little confused on your explanation. I am not sure what index0 is and what the next new index available field is. Would you please give a little more information on those two.

Thanks,
George
 
PgmrChris,

I think I followed your instructions correctly but am
still unable to get data into the IMH table. Here is what I did. There are no records in IMH except for the 2 that are always there.

1) I got the value of LinkToNextLine from the first line of data which was 1 (I think that is index0).
2) I did an insert into IMH with my data where the transactionType = NULL.
3) I did an update to LinkToNextLine by adding 1 to the first line of data which I believe to be index0.

I found my data update did not work (No error message) and I received the error message on the increment that said: Unable to determine files primary key.

Thanks for any help that you can give me.

George
 
George, that is just what I got. I never did figure a work around for this. We endedup buying Visual Integrator which worked great for inserting the transactions.
 

The IMH transaction type s/b one of the following values:
&quot;1&quot; = Sales
&quot;2&quot; = Issue
&quot;4&quot; = Transfer
&quot;6&quot; = Adjustment
&quot;8&quot; = Receipt

Here's what you may want to do to check out the state of your data (I would *STRONGLY* suggest you do this in a test or backup company, so you don't risk mangling your live data):
From the utilities menu, run the file analysis and repair utility. When prompted for a filename, enter IMGXXX.SOA and hit return.
Click the browse button to peek at the IMG records. MAS90 strings together it's non-numeric data.. so the first data item you'll see in each record is the combination of all of your string data. If you want to get a better visual representation of what these records look like, see if you can find the TRSG (technical reference something something) CD that came with MAS90--it's got the file layouts in it..or e-mail me & I'll send you a .pdf file). After the string data is the numerics.. the first numeric in IMG points to where the first detail record in IMH is stored. You don't have to risk wrecking your data in this utility unless you click the delete or the edit button. You can click on the filename field to enter a new filename. I suggest you check out IMH next.. you should see that index #0 is different from everything else. Index 0 simply contains 4 numerics--it is used to maintain the file & doesn't store any actual transaction entry information. Check out index 1.. you should see something like this: field1 is the &quot;key&quot; from the IMG record that this detail line belongs to. It should be a transaction type (1 byte) + a reference number (10 bytes)
The 2nd field is numeric, and it is the link to the previous detail line. If this is the first detail line entered for this transaction, this number will be zero. The 3rd field is also numeric, and it is the link to the next detail record for this transaction entry. If it is zero, this is the last detail record. The 4th field is the string data for the detail line. Fields 5+ are all the numeric data for the detail line. Enter a transaction in inventory transaction data entry & then browse the IMG/IMH data files via the utility I mentioned & you should be able to see what a valid transaction looks like.
Hope this helps! Index files are definately not easy to work with -- even when you use the native language..

-Chris







 
Chris,

Thanks for the info. It is pretty involved. I am playing with it now and hopefully I will get this solved soon. I may end up asking another question later. Thanks for being patient with me. BTW, I do have the TRSG and have installed it. I will take a look at it too.

BeejCyr,

If you want I can let you know if I solve this and give you the solution although I am sure you don't want to see this again.

George
 
Chris,

I now understand how everything works in IMH but I am
still unable to get data into that table using SQL. I
have tried updates and inserts but each fails. I tried
to get the data into the table by trying to input it
the same way the structure looks in file analysis and
repair window. That also failed. I don't think SQL will
be able to update this table because I have to name the
columns from the table structure and since it is an index
table it does not have a key of any sort. You are right,
index tables are definately very difficult to work
with. Is there another way to get data into the table
other than an SQL statement? I think if I can't solve it
soon I will have to get the visual integrator like
BeejCyr did. Thanks for any help you may have.

George
 
I'm sorry I don't have more info for you, but I've never attempted to push data into a MAS90/Providex index file using a SQL statement.. I've always used the native Providex language when dealing with these. Here's your options on this guy:
(1) Visual integrator
(2) Paying a Master Developer for a custom program (careful, becuase custom code may hinder your ability to upgrade)
(3) Using ODBC/SQL statements
(4) Using the C++ routines <- I'm not sure if these are still available. Check out Basically, they had C++ library you could purchase that would do the interaction with native Providex files. It did cost you something--I don't remember how much. I've never used them, so I can't vouch for their performance.

Best of luck!
-Chris
 
Chris,
Thanks for the information. I guess I will give the makers
of the ProvideX ODBC driver a call to find out about the
native ProvideX language or if you have time point me in
the right direction to get started with that language.
Thanks alot for all your help. I now have a very good
understanding of the transaction tables for inventory
management.

George
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top