What is REPTPASS used for 1

[vbajock]

Using Macola 7x, btrieve, noticed that a file called REPTPASS gets updated whenever an order changes status. Just wondering if anyone can tell me what it is doing.

 

[MacolaHelp]

It's used to temporarily sort & store information you select in the report parameters. It would also send the info specific to the print default file about the user and the job to the printer. It's a temporary file & can be initialized as needed if no one is printing reports & needs to be initialized when you have lockups or blowouts during processing.

 

[vbajock]

How do you define a blowout? I had a situation where after uploading an order thru Access the OEORDHDR file mysteriously deleted every record. Luckily we were doing this in a test company, but as yet we have no explanation as to why it happened. Since we did not update this file, it has been one of the possibilities we have looked at, but from what you are saying it doesn't sound like it matters.

 

[MacolaHelp]

My take on "blowouts" is impatient or panicked users. They either ctl-alt-del before a process is completed or do something like hitting the power cord or power switch during a process that is doing read/write. Or, my personal favorite, killing the job during a purge they accidentally started. If a report is being generated when they abort the program abnormally, it will sometimes hang print jobs subsequent users try to generate. Initializing reptpass usually fixes this problem. Since it is a temporary file & cobol based, I doubt if your oe header problem could be related. The reptpass file is used by all apps & is updated everytime a print job is processed. I imagine the printing pick tickets & pack slips update reptpass, but probably not select for billing, which produces no report but changes order status. Only on demand billing reports should update reptpass.

You might consider if you have a page locking issue with the access upload on your btr file. Though, why it would delete records rather than warn is mysterious. Creating orders externally is a pretty complex process, so there could be lots of possibilities. Good luck.

 

[vbajock]

We sent the file to Goldstar Software for a look. They were able to recover the file. They said it looked like somewhere on the network someone had run an init or a delete query. I'm not so sure. We are trying to upload an order that has a status of being a picked order and is selected for billing. Before we wrote the program, we entered, picked, and selected an order manually, and then coded it to mimic the process. The test order uploaded fine. The problem happened when we manually unselected the uploaded order, then re-selected, printed and posted it. We got a nice invoice, and the test orders hit AR correctly, but the OEORDHDR file just blew up. In butils it showed 0 records. We are still scratching our heads as to why this would happen.

 

[dgillz]

If your update Im for orders flag in OE Setup is set to B-Bill, when you post the invoice, the records in the ORORDHDR and OEORDLIN are deleted and moved to the ORHDRHST and OELINHST respectively, provided that there is no backorder.

This is expected behavior.



Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[MacolaHelp]

Picked is status 4, selected is status 8 in oeordhdr. There is also the select_cd in oeordlin. Also, are you writing to the iminvtrx for the allocations for these orders? I have seen program disasters created by not completely replicating the macola order entry process. If you forget to create allocations in iminvtrx, posting based on bill update will often choke & you'll get allocations failed. Other files could also be haunting you, especially if you have kits, feature items, PP pull items, etc. Kind of sounds like oeordhdr & oeordlin were out of sync in their statuses. Unselecting would probably really have confused the program.

 

[vbajock]

The expected behavior is not the problem - it unexpectedly eats the whole OEORDHDR file. After you mentioned this I went back and checked to code to make sure it wasn't accidently coded to change all the select codes in OEORDHDR, but that is not the case. The records are loaded to buffers first, and then the buffers are appended to the btrieve files. We are not doing any changes to existing records.

 

[dgillz]

When you say "The records are loaded to buffers first, and then the buffers are appended to the btrieve files."[/i} What exactly does that mean? Where do you store buffers? Why are you not doing a simple append query from MS Access?

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[vbajock]

The buffers are Access tables. We load the tables with XML coming in from the Internet. We then upload the tables using simple Access append queries. Worked great with our MS SQL clients, but for some reason, the same approach is wacking this file in our PSQL 2000i Btrieve cleint. Have you uploaded orders successfully using Access to a PSQL database?

 

[dgillz]

Yes I have loaded orders from Access to Macola in both PSQL and MS SQL environments. I have never heard of a buffer before, which is why I asked the question. I have never worked with an XML data source either.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[vbajock]

A buffer is just a one record holding area that is a structural copy of a target table in the database. You use it to append records one record at a time, and you use a group of buffers to update a group of target tables. The buffer could be a database record, a text file, or a temporary place in RAM memory. It allows the programmer to group updates to a bunch of different tables together into a "transaction" which is passed to the transaction processor in either PSQL or MSSQL. The transaction processor only updates the actual underlying tables if all table updates succeed. If one update in the group fails, it rolls back all the updates to all the tables in the transaction group. This protects the database from getting updated with half-completed transactions if the power goes out or the user crashes the machine.

 

[MacolaHelp]

Are you looking at the status in oeordlin or BOTH oeordlin & orordhdr?

 

[vbajock]

In the header, I'm using:

SELECT_CODE = "S"
ORDER_STATUS = "8"

I don't see a status field in OEORDLIN. I am using "S" as the select code.

 

[vbajock]

Ok, we found a code typo that my have a bearing on this. The field "CUSTOMER_BAL_METHOD" was inadvertently set to 0 (zero) instead of the letter "O". Can anyone explain what this field does exactly?

 

[vbajock]

Also, on OEORDHDR, I have a field called PRE_SELECTED_STATUS. I can't find any documentation on what the status code definitions are for this field - any help would be appreciated!

 

[MacolaHelp]

In oeordhdr, you have status 4 picked, 8 selected
you have selection_cd = 'S'

In oeordlin you have select_cd = 'S' & no status field like in oeordhdr. This is because you might not select all lines on an order to be billed at one time (due to backorders, usually). If you are looking at both files, then I can't imagine why all the records would be dropped in oeordhdr.

 

[vbajock]

If anyone is interested the bug was caused by
CUSTOMER_BAL_METHOD being set to the number 0 instead of the letter O. Why this causes Macola to eat the OEORDHDR file I do not know.

 

[maccrystal]

Customer_Bal_Method flag is used to tell A/R if they are using Open Item or Balance forward accounting method. Open item you pay against the individual invoice, balance forward, you pay against the open balance without referencing the invoice.

http://www.appstratinc.com

 

[vbajock]

Thanks. All you Flex dudes, watch out for this - if you set it to zero by mistake (instead of the letter "O&quot it triggers something inside Macola - when you post invoices in Macola, it eats the OEORDHDR file in the PSQL version.
I have no reason as to why it would do this, but it does.