I get the following error message when I try to open RM-A
An error has occurred while trying to open file - DEFAULT\ISRMAC.B - 12
Press okay
An error has occurred while trying to open file - DEFAULT\ISRMAI.B - 12
Press okay
Module opens.
Closes without any errors.
 

Running NEWINIT caused me to get a warning error on every file in the data base
 
"An error has occurred while creating file AS\BKABCUST.BAS - 11"
click OK
next error...........................................................................
..................
and so on all the way down the list of files.  
I pressed OK too many times to record here.
 
A better suggestion would have been to run DBAIF on the two files mentioned in my previous posting.

So, we're happily using the new RMA module. Seems to be doing fine so far with serial numbers, etc. But we noticed something that does not work the way we would expect.
 
When entering the RMA it asks for the original invoice number. However, when dispositioning items to return to stock, the line items pull their prices from the Base price, not from the invoiced price. It doesn't even ask for the price when dispositioning, it just makes the return-to-stock SO with the system base price. This means that we have to do the extra step of opening the SO and changing the prices. I can hardly wait to see what it does for replacement SOs. Is it possible that it makes out the replacement SO at $0.00, as it should, or does that pull the base price, too?
 
Or maybe I'm doing something wrong. I don't see any SD-Q settings for this.

How about the notes? Shouldn't they pull into the SO or SR?

Any time an update with new programs or modules is installed, you need to go to the password security and enable the new options.  In DBA Classic, they will be greyed out until you go to PS-B and turn them on.  In Evo-ERP, they will only be available on the ADMIN menu until you use TAS-G and add them to other user menus.

RMA uses the same Header, Lines and Notes files as SR.  ISSRINV, ISSRINVL and ISSRDESC respectively.  RMA also uses ISRMAI for the RMA info, which is tied to ISSRINVL lines, and ISRMAC for the RMA Reason Codes.

The SR is actually using 'Y' for closed SR but SR-A converts to an on-screen 'C'.  As for the data, it appears to be enough information in the RMAI file.

Colin,
You are right ... You can't write to the .DDF files if there are ODBC connections open.
 
I also wanted to mention to you that if you have added views or security to the ODBC data source, running
ODBCDDF will remove all of them.
 
I keep my views and security stuff in a SQL script so that if I refresh my .DDF files, I can re-enable all the
other stuff that makes all my ODBC stuff work.
 
Just an FYI!!  

A view is essentially a fake table that takes it data from other tables. It's dynamic in that it regenerates it's contents on every select statement. For instance, lets say you have two tables called TableA and TableB. TableA stores customer account details such as name, address, and so on. TableB stores sales order data. Now, obviously you'd normally have a foreign key in TableB that links it to a record in TableA to specify which customer is ordering. But what if you'd like one table that stores records with the customer's name and the total price for each sales order. With a view you could construct such a fake table that had those sort of records. This allows you to issue SQL statements like:  
 
select * from FakeTable where CustID = "KMFG100";
 
which could definitely be more readable than the equivalent query to get the data out of the two original tables.

One of the nice things about views is they enable you to put all of your select criteria into the database instead of the application.
If a table definition changes that may affect your select logic, you just re-define the view instead of modifying the application.
Your application would just have a simple select all type statement (i.e. select * from <viewname>)
 
I use a view that defines all of the orders that are ready for shipment.  The Special part of the view is a nested IF statement that extracts  
an email address from one of 4 different locations in the sales order.  It first checks the sales order notes, then the Description, then the 5th
contact in the BKARCUST, and finally the 1st contact in BKARCUST.  With an email address, our shipping system (CPS) can email a 'ShipElert'
that notifies the customer that a shipment to them has been processed.  This email contains the Shipping info and a tracking number.
 
 
 

Quote from kkmfg on 09/27/07 at 06:15:36:

 
I tried to run  NEWINIT because my DDCheck shows 500 errors most all of which are a play company we deleted long ago and now it has mysteriously appeared...   well kinda re-appeared.... there is not a folder for it in DBAMFG but the files are showing up in MAINTAIN DATABASE along with some other previously deleted test companies.   After reading this thread I think I need to figure out what DBAIF is.