ACTIVANT STANPAK. Open Gateway SQL Tips. Version 6.0

Transcription

1 ACTIVANT STANPAK Open Gateway SQL Tips Version 6.0

2 This manual contains reference information about software products from Activant Solutions Inc. The software described in this manual and the manual itself are furnished under the terms and conditions of a license agreement. The software consists of software options that are separately licensed. It is against the law to copy the software on any medium, or to enable any software options, except as specifically permitted under the license agreement. In addition, no part of this manual may be copied or transmitted in any form or by any means without the prior written permission of Activant Solutions Inc. From time to time, Activant makes changes to its software products. Therefore, information in this manual is subject to change, and the illustrations and screens that appear in the manual may differ somewhat from the version of the software provided to you. Created by: Yardley Technical Communication 2006, Activant Solutions Inc. All rights reserved. Activant and the Activant logo are registered trademarks and Activant Prophet 21 is a trademark of Activant Solutions Inc. All other company or product names are the trademarks or registered trademarks of their respective companies. Activant Solutions Inc Southfront Road Livermore, CA Version 6 Publication Date:

3 Introduction - Mining for Information Stanpak Open Gateway SQL Tips Have you ever been mining? Not for gold or diamonds or some other valuable mineral, but mining for information. You have lots of information buried in your computer system. It s just sitting there waiting for someone to dig it out and refine it into pure value. The Stanpak database is a rich source from which to mine for information a veritable motherload. Its very extensive database, including invoice history, allows users to capture just about any data not collected in transactional history. Sounds like an idea that could be very profitable. Imagine all the information in your software system all that data that s been locked up in that box we call a computer in the corner of your office available to Microsoft Excel and Access. You could find out just about anything you wanted to about your business, or for one of your customers. What kind of magical tool can make this happen? It s called the Stanpak Open Gateway SQL solution. SQL is short for Structured Query Language. Coupled with an ODBC driver (another candidate for alphabet soup, ODBC stands for Open DataBase Connectivity) to feed the results of these queries into such popular programs such as Microsoft Excel or Access, you have a tool to mine your database a gateway between the data in your mainframe computer and the graphics based richness of the PC world. It dynamically links the full Stanpak database to any ODBC compliant PC software making it look to these programs like a relational database that resides on your PC. A Change in Strategy It is impossible for Stanpak to anticipate every report each user might need, but it is possible for Stanpak to provide a gateway for users between the Stanpak database and the most popular PC analysis and reporting environment. With the Open Gateway SQL server, it is easy for users to create and save ad hoc reports. As we shift to more use of the SQL server with its ability to serve Excel and Access with their more powerful reporting and graphical presentation capabilities, we believe we will see a shift in the way software is developed. By adding invoice history to the Stanpak database, we have provided users with a path for capturing just about any information they might wish to have. As an example, customer and customer-by-item fill rates can be calculated using Qic/LOOK in a two-step process from the invoice history files. First select and sort orders by Customer and date range, sending the results to a work file. Than from the work file, summarize the order line records associated with these orders for picks and backorders, calculating fill rate by customer or by-customer-by-item. With the new SQL, it would become a one step report that could be created, saved, and run as often as you wish. Fill rates by day or week for the company can also be done the same way. Using Excel Pivot Tables, this information can be quickly reported by customer, by item, by vendor, by salesman or by any combination of information imaginable. Stanpak Open Gateway SQL Tips Page 3 of 10

4 Defining and Enriching the Stanpak Database The SQL Data Dictionary uses the file definitions provided by Stanpak in the #FILES, which also define the file structure for the Qic/LOOK Report Generator. To an ODBC compliant product, the SQL Server makes the Stanpak database look and act like a relational database. You just select the data elements that you want and the Server will fetch them and import them into your spreadsheet or database document. It is fast and seamless. In order to enrich the Stanpak database to allow the new Stanpak Open Gateway SQL to have expanded reporting capabilities, several new programs have been created to build files with data that would be very difficult to calculate, but is very useful for reporting. The BCBI Pricing File Builder Program BE creates a new BCBI customer pricing file (BCBIP) with records with current price for every item and customer record in the BCBI file. It uses the same algorithms used by order entry, taking into account price changes, contracts and policy pricing to yield the same price that would be automatically assigned if each item were entered in order entry. Each record in the file contains a customer number, item number, price and pricing unit. The file layout has been added to the #FILES specifications and appears as BCBI_PRICE. This program must be run immediately before reporting from it to insure that the information is fresh and up-to-date. The Item Catalog Pricing File Builder Program I1E creates a new item catalog pricing file (I1P) and loads into it records with the catalog pricing and quantity breaks for every item in the item file I1A. It uses the same algorithms used by the catalog print program. Each record in the file contains an item number, quantity break and price for each of the eight possible price breaks. The file layout has been added to the #FILES specifications and appears as PRICE_BOOK. This program must be run immediately before reporting from it to insure that the information is fresh and up-to-date. Using the Product We have been working with it for several months and have learned a little bit about some of the idiosyncrasies within the product. By reading the following, you can learn how to increase your speed and satisfaction in creating reports. Tips for Microsoft Query 1. Once you are in Microsoft Query, shut off the Auto Query option on the Record pull down menu. This will prevent the program from executing the query with each change in your specification. The execution of a complex query on multiple large files could take 3 to 5 minutes and the delay can be very frustrating. Stanpak Open Gateway SQL Tips Page 4 of 10

5 Instead, finish the specification and click on the Query Now button on the tool bar to execute the query. Query Now Button 2. There are several files in the Stanpak database that have multiple record layouts. The SQL expects to see all records within a file with the same layout and will have problems with these multiple-layout files unless properly managed. The Multiple layout files are as follows: Invoice History Header File Order Header A Record Order Header B Record Invoice History Line Item File Order Line Item Record Order Total Record Order Header File Order Header A Record Order Header B Record Order Line Item File Order Number Count Record Order Line Item Record Order Total Record Purchase Order Header File P/O Header A Record P/O Header B Record Purchase Order Confirmation Record P/O Confirmation A Record P/O Confirmation B Record Call Collection Misc. Record Collection Misc. A Record Collection Misc. B Record System Master File Z1 Too many to list When Adding Criteria in Microsoft Query to a Multiple-layout file, do not press the Value Button to see the available value option. Doing so will hang the program and spoil your query. Stanpak Open Gateway SQL Tips Page 5 of 10

6 3. Reading Multiple Layout files with the SQL requires a special technique. The Data Dictionary (#FILES) defines each layout as a different file. In Microsoft Query, you will have to select each layout you wish to look at as a different file. In addition, you will have to enter select criteria for each format that will exclude the other format from being read to prevent the system from seeing the other file layout as file corruption. An example of this is the Order Header File, which contains an Order Header A Record and an Order Header B Record. The A record contains the Order Header information and the B record contains the ship-to information. When reading the A records, the Add Criteria option must be used to select the A_CONSTANT_ID and include it if it equals "A" The following Criteria should be used for the following multiple layout files: Order Header File Order Header A --- add Criteria A_CONSTANT_ID EQ A Order Header B --- add Criteria B_CONSTANT_ID EQ B Order Line Item File Order Line Item --- add Criteria TOTAL_TEST NE TOTAL Order Line Total --- add Criteria TOTAL_TEST EQ TOTAL Invoice History Header File Order Header A --- add Criteria A_CONSTANT_ID EQ A Order Header B --- add Criteria B_CONSTANT_ID EQ B Invoice History Line Item File Order Line Item --- add Criteria TOTAL_TEST NE TOTAL Order Line Total --- add Criteria TOTAL_TEST EQ TOTAL Purchase Order Header File P/O Header A Record --- add Criteria PO_CONSTANT EQ A Stanpak Open Gateway SQL Tips Page 6 of 10

7 P/O Header B Record --- add Criteria PO_CONSTANT EQ B Purchase Order Confirmation Record P/O Confirmation A Record --- add Criteria CONSTANT_A EQ A P/O Confirmation B Record --- add Criteria CONSTANT_B EQ B Call Collection Misc Record Collection Misc. A Record Collection Misc. B Record --- no criteria will work - do not access this file --- no criteria will work - do not access this file Customer Miscellaneous Record Customer Miscellaneous A Record ---add Criteria CONSTANT_FLAG EQ A Customer Miscellaneous B Record ---add Criteria CONSTANT_FLAG EQ B Customer Note File INSTR_COMMENT Customer Billing Note Record ---add Criteria INSTR_CODE EQ B Customer Delivery Note Record ---add Criteria INSTR_CODE EQ D Customer A/R Note Record ---add Criteria INSTR_CODE EQ R System Master File Z1 no criteria will work - do not access this file Note: MS/Query places an underscore _ in place of the period. we are accustom to seeing in Qic/LOOK as is the practice with PC relational database representations. These criteria assume you are using the new #FILES released either with Stanpak release 4.05 or Stanpak Open Gateway SQL Should you kill the Query program while running Excel by using the Control, Alternate and Delete keys or should the Microsoft Query hang for some reason, you will probably have to not only close Microsoft Query, but also close Excel and restart Windows. This seems to be a Microsoft problem. Tips for Microsoft Word Information can be imported into Microsoft Word through the Mail Merge option. This feature allows you to select customers based on specific criteria and set up a document or letter accordingly. Customers who are past due could have letters created and individually addressed with values such as the addressee ("Dear John") and the amount due inserted right into the letter. There is a known bug is Microsoft Word that limits the size of each block (record) of information that can be transferred into Word to 256 bytes. Microsoft is working on fixing it, but you do not want to be blind-sided by trying to make something work that should work but does not. The solution is to plan what you need to bring across for the Stanpak database. Stanpak Open Gateway SQL Tips Page 7 of 10

8 The following file layout sizes may help: Data Dictionary CUSTOMER_NAME 25 CUSTOMER_ADDR1 25 CUSTOMER_ADDR2 25 CUSTOMER_CITY 15 CUSTOMER_STATE 3 CUSTOMER_ZIP 9 ATTENTION LINE 18 A/R_TOTAL 11 A/R_CURRENT 11 A/R_OVER_30 11 A/R_OVER_60 11 A/R_OVER_90 11 A/R_OVER_ We will be providing you with a new Data Dictionary (#FILES) which will replace your old one. Because of changes in specifications and enhancements designed to improve the speed of Qic/LOOK, it will be necessary to replace your old #FILES rather than merge the new changes into them. This will cause you to lose any local links, definitions or field or file definitions that you may have previously specified for use with your own Qic/LOOK and Report Generator reports. They will have to be recreated in the new #FILES using the program *FILES if needed. Stanpak Open Gateway SQL Tips Page 8 of 10

9 Understanding Microsoft Query and the SQL Understanding how Microsoft Query and the SQL execute will help you to save time and avoid frustrating traps. It is also the key to designing Queries that run efficiently. The problem is that once the SQL begins to execute, it cannot be stopped and the operator must wait until it completes. While some queries execute quickly, others that are poorly designed could take 5, 10 or even 20 minutes to execute. Microsoft Query expects to execute the query you are building every time you make a change to show you the result of the change. While this is an effective strategy if the query is a simple query operating on a small file, a complex query on a large set of files would be unwieldy and slow, and could take excessive amounts of time for every iteration. Your strategy should be to turn off the features that cause the query to execute automatically after each change, and avoid actions that cause the query to execute unnecessarily. First, it is important to understand the way Microsoft Query acquires and displays sample information. The information returned to the screen during the building of a query is not a complete list. It is instead, just the first 100 records returned from running the query. This is important to understand or much time can be wasted. Using the slide bar to the right of the screen to display records beyond the first 100 will cause the query to continue, and to deliver the next 100 records. If the query results in thousands of records, clicking on the bottom of the slide bar to go to the end of the file will cause the query to continue executing to deliver successive 100 record results. If this happens, go get yourself a cup of coffee. Executing in this fashion will take much longer than a normal query run. The same thing will happen if you click the EOF button on the lower left of the screen to see the total number of records returned. You have been warned. Looking at an extremely large file with a simple query returns the first 100 records, and taking no time at all. Of course, the system is only reading and returning the first 100 records. Add a criteria to select records for which there are no matches or fewer than 100 matches will cause the entire file to be read in order for the query to attempt to accumulate the first 100 records returned. If the file being queried is hundreds of thousands of records, you might get sick from drinking too much coffee. Of course, when the query is finally finished and being executed in production, the delay is tolerable; but if you are sitting there waiting and anxious to work on your query, as the captain in the old Katzenjammer Kids comic strip used to The SQL has its own idiosyncrasies. Often surprising or unexpected results are caused by the inherent way the SQL executes. A Key is an index or pointer that helps a computer organize its file structure and allows quick access of a record without reading the whole file to look for a record. It works just like the index in a book. When reporting files with simple keys, like the customer file (customer number) or item file (item number), the query will zip through the file with surprising speed if you are using the key as criteria. This will also be true if you are using the key to join (link) a file to another file. The opposite results if you are not using the key. Let's say you wish to look at sales history through the BCBI file. The BCBI record has a complex key made up of the Customer Number + Stanpak Open Gateway SQL Tips Page 9 of 10

10 Category + Item number. A query that links from the customer to the BCBI to the Item file would execute fairly quickly because in each case the SQL has a key to guide it. In the case of the BCBI it is not the full key but it is the beginning of the key. The query would not have to read the entire BCBI or Item files but would go directly to the target records. Lets take a worst case a query that reports each item and the customers that purchased it (seemingly the same information as in the previous paragraph). One would expect the query to take the same time to execute. However, having no primary key to guide it from the item file directly to the correct record in the BCBI file, the Query will read an item, and then read the entire BCBI to find matches. It will go back and read the next item and again read the entire BCBI. If you had 2,500 records in your item file, the query would read through the entire BCBI file 2,500 times. As you can see, if you are creating complex queries, planning your attack to determine the most efficient approach can save lots of time. SQLs are actually designed to optimize the time required to execute a query. Most of the time they work very well, but sometimes you get unexpected slowness. Many times, the efficiency of an SQL comes from proper file links, or joins as they are called in the database world. Joins have different characteristics. The three types of joins are: Type of Join Characteristic Example one to one joins 1 record to one other record Customer to Customer History one to many joins 1 record to many related records Customer to Ship-to many to one joins many records to one record Purchase orders to Vendor When creating joins that do not link the key of one record to the key of another, setting the join to the proper relationship will significantly improve the performance of the query. This is accomplished by clicking on the join after it has been created. This will bring up a dialog box, which will allow you to make the choices. As you can see, using the SQL for simple file lookups can be easy. However, building complex queries that execute efficiently will require you to develop a skill set that can only be acquired by gaining some in depth knowledge of the workings of Microsoft Query and practice. The good news is that once you have the query set up properly, it will run on its own, taking no more of your time. Incidentally, I could not find the information contained in this chapter anyplace in the Microsoft documentation or in any other books on the subject. It was acquired by trial and error, and a good deal of coaching from Mick Galvin of Qantel Technologies. Stanpak Open Gateway SQL Tips Page 10 of 10