"color; @COLOR function; error; message; error message; dada; 2F03; DADA 2F0; table; table view; view; Alt-F6; Alt/F6; Alt F6; 1461"," ","Error message DADA 2F03","5",1461, ,"Jun 29, 1996","This error message occurs in conjunction with the @COLOR function. The error occurs when @COLOR changes a field, then Alt-F6 is pressed and you attempt to move from the current record to another while still in Table View mode. (There is NO error while moving left or right on the same record's row, only when moving to another record. If @COLOR does NOT change a field, then everything works fine.) (Thanks to Carl Underwood for the above information) I found that page down or page up will work OK. The solution should be fairly obvious: (1) remove the temporary @color change programming, (2) if you leave the temporary @color change programming in place, then don't use the down arrow when in table view (ugh!, not a happy solution) or (3) use page up/down to navigate through the records."," "," "," "," "," "," "," "," "," " "printer; printers; setting; settings; global; global setting; global settings; tray; new tray; trays; new; bin; bins; print; print setting; print settings; default; default setting; default settings; printer setting; printer settings; change; 1462"," ","We have recently added an additional tray to our HP4 printer. How do I make this the default tray for Q&A?"," ",1462, ,"Jun 27, 1996","For word processing documents, from your Q&A Main Menu, select (W)rite, (U)tilities, (S)et global options, (P) - Change print defaults. On the seventh line, 'Type of paper feed,' select whichever bin is appropriate for your new tray. Press F10 to save your new settings. This will NOT change the type of paper feed for any existing documents. That you will need to do one-by-one, as needed. Then simply saving each document (F8) will save the new paper feed settings along with the document. For database programs, select (F)ile, (P)rint (any database file name that you want to change), (S)et global options, (A) - Change print options defaults. On the third line, 'Type of paper feed,' select whichever bin is appropriate for your new tray and save (F10) the setting. Repeat the process but instead of (A) - Change print options defaults, select C - Change single form print defaults. New databases will conform to these new specs. This will NOT change the type of paper feed for any existing databases (other than the one(s) you specifically selected). That, too, you will need to do one-by-one, as needed. I hope this information is helpful and wish you the best of luck with your new equipment. Enjoy!!"," "," "," "," "," "," "," "," "," " "Report; spec; specs; report spec; report specs; copy; copy design; retrieve; retrieve spec; garbage; bug; flaw; error; 1463"," ","Last Friday I used Q&A 5.0 copy design only to work on the database (thats been working well ) without any records. After completing my changes I copied the records over to the new database and thought all was well. -- Wrong -- Monday morning I start getting complaints about reports now working correctly. After further examination, I find that the last field in the Retrieve Spec contains either garbage and/or what appears to be part of a column spec entry. Since I don't use this field as part of the retrieve spec. It appears that Q&A is not breaking the end of the Retrieve Spec from the Column Spec properly. I examined the database design only that I used and sure enough the same problem existed. I tried copying the design from a saved master (which I checked first to make sure the last field in the Retrieve Spec of the Reports was ok) and the same problem accured on the new copy. Since I didn't add, remove or modify any of the 62 reports, my question is what happened????? The only way I was able to make it work was to copy the entire database to a new location, then remove the records, use database recovery to rebuild the index, make the changes I needed to the design and when finished copy the latest records from the active database to the new design. Since this database contains 155 fields with 7,000 records and growing, this later method is not very practicle. The primary reason I like to copy the design is so that I can work on it while the database is in use and later when it becomes available, copying the latest records back cleans up the database because the deleted records will not be copied back. Does Q&A 5.0 have a Bug here or what??? <<<< Please advise>>>>","5",1463,27,"Jul 2, 1996","I have no way of knowing whether or not your experience is a 'flaw' in v5. I can tell you that (1) I don't recall it having been a topic of general discussion and (2) it DID happen to me on one occasion, with one client in one particular database. Since only one report was effected, I simply redesigned the report and there was no further problem. My initial suggestion would be that you redesign the reports by simply removing the 'garbage' in the last field in the retrieve spec and see if that 'fixes' it."," "," "," "," "," "," "," "," "," " "key word; keyword; keyword field; blank; blank field; invisible; invisible field; field; 1464"," ","I received the latest Q&Answerman database and there is one interesting quirk that I noticed. When I do a (F)ile (S)earch, and then press at the retrieve spec screen to go direct to the DB, I wind up in the field you call 'The question you have is'. The quirk is, the KEY field, that one usually searches on, is NOT displayed; it is blank. If you go forward or backwards (F9 or F10) through the records, it remains blank. Yet if you TAB (or HOME HOME) to the KEY field, it fills up with its contents. I have checked this several times; it does it every time. Any explanation?","5",1464, ,"Jul 2, 1996","There is no 'quirk' in The Q&Answerman database (at least not as you described ). The first field you're referring to is a 'KEYWORD' field used strictly to facilitate finding records. Since, once you find the record, the field itself serves no purpose, I made the text and background the same color, to eliminate the 'clutter.' When you search for a record (and/or press F9 or F10), you are not in the field (based on a simple 'goto' statement) and, therefore, don't see anything. When you Shift/Tab, the cursor goes into the field and then (as it should be) displays the text. I'm glad that 'it does it every time.' It's supposed to. Actually, I think this is a 'cute' question, so I'm going to add it to The Q&Answerman database. "," "," "," "," "," "," "," "," "," " "compare; change; changed; added; select; selected; different; difference; differences; match; don't; don't match; non-match; non match; non matching; non-matching; unique; recent; most recent; selective; different; compare; choose; report; search; retrieve; retrieval; retrieve spec; spec; 1465"," ","I am looking for a way to compare 2 databases which contain mostly identical information, ie one is from April and the other from may, I would like to be able just to look at the records that are different form month to month, that is added or changed? Any suggestions? I looked into the QnAnswerman and see the method to check for differences in a record having a common menber, but can't seem to make the jump from there to looking at differences where they may be no common item. Thanks for your suggestions in advance."," ",1465,36,"Jul 4, 1996","This is a difficult question to answer because there are many ways to approach it and many 'points' that need to be clarified. There are, however, at least 3 additional records in The Q&Answerman database that might be helpful in this regard and I hope I can steer you in the right direction. (Each of the records are identified as XRef #36). First, you say you want to 'look at the records that are different from month to month, that is added or changed. Finding 'added' records is a somewhat easier than 'changed' records. If possible, it's best to plan ahead to be able to identify records that are changed as it occurs. In this regard, I suggest a date field that will record the most recent date the record was changed. That way you could compare the date field between databases to identify that changes were made. (Not only would you know that the records are different, you would know which one is the more recent). With regard to 'comparing and looking at the records that changed,' one way to accomplish this would be to prepare a report that would identify the specific records. You'll find guidance on how to do this in Q&A Application Note #2211, Reporting Differences Between Databases (Record #989 in The Q&Answerman database). The only modification you would need to make is that you would need to create a report in each of the two databases. The report in the April database would identify any differences between records that are in both databases AND any records that are IN the April database and NOT in the May database. Likewise, the report in the May database would identify any differences between records that are in both databases AND any records that are IN the May database and NOT in the April database. The next point that concerns me is that you say there 'may be no common item.' I'm not sure what you mean by this, since you MUST have something in common between the two databases in order to make any kind of comparison. If you simply mean that some records won't have a 'mate' in the other database, then there is no problem. The technique I just recommended (along with another that I'll suggest) will take that into consideration. If you don't have a field on which to 'match' then you must create one. A 'full name' would be a good field to consider. If your records have first and last names in separate fields you can easily combine them. You'll find guidance on how to do this in Q&A Application Note #2101, Full Names and Component Parts (Record #116 in The Q&Answerman Database). (Be sure to make the combined name field (S)peedy). Finally, since you say you 'would like to be able just to look at the records that are different,' then you might only need an 'xlookup retrieve' spec. You'll find information on this approach in The Q&Answerman database (Record #228). I sometimes prefer to 'mark' the records by adding a field called 'Match.' Then, I do a mass update to perform an external lookup, and when a matching record is found, I enter an 'X' in the match field. (I do this in both databases). Then I can search for all records that DO (X) match as well as those that DON'T (=). Yet another option that was recommended (thanks Michael Borufka) is simple and easy: Essentially, he says 'Copy all records into one database. Then choose F)ile, R)emove, D)uplicate records (you can specify what means duplicate for you) - BINGO ! The new db contains ONLY the different records. Of course, you could wrap all this up into a macro, start it from a menu or even programming.... the possibilities are endless!' I hope that one (or a combination) of these ideas will point you in the right direction and enable you to accomplish exactly what you want. Good luck!"," "," "," "," "," "," "," "," "," " "error; spec; form; design; form design; copy; copy form; copy design; copy form design; text; format; format value; format values; value; values; formats; number; n; report; reports; reporting; change; changes; database; database change; database changes; error; erros; retrieve; retrieval; retrieve spec; retrieve specs; 1466"," ","COPY DESIGN ONLY: I used Q&A 5.0 copy design only to work on the database (that's been working well) without any records. After completing my changes I copied the records over to the new database and thought all was well until I found that REPORTS were not working correctly. After further examination, I found that the last field in the Retrieve Spec contains either garbage and/or what appears to be part of a column spec entry. Since I don't use this field as part of the retrieve spec, it appears that Q&A is not breaking the end of the Retrieve Spec from the Column Spec properly. I examined the database design only that I used and sure enough the same problem existed. I tried copying the design from a saved master (which I checked first to make sure the last field in the Retrieve Spec of the Reports was OK) and the same problem occurred on the new copy. Since I didn't add, remove or modify any of the 62 reports, my question is what happened????? Does Q&A 5.0 have a Bug here or what???"," ",1466, ,"Jul 7, 1996","THE PROBLEM: First, let me point out that there has been substantive discussion of this issue on the CompuServe forum (and elsewhere), so apparently it is a fairly widespread problem. In this particular case, the problem occurred on a network; however, it was replicated on a stand-alone PC. MOREOVER, there have been numerous experiences - mine included - where the problem has occurred on a stand-alone machine. I experienced the problem with one client on a network ... and another where the database had never even been NEAR a network. In both cases, it occurred with databases that had been upgraded from version 4 to version 5. Moreover, in nearly every other instance, the problem has occurred when a version 4.0 database was converted to version 5.0. The only exception to this (that I'm aware of) was made by Alec Mulvey who stated 'This is not a QA5 issue. It is seen on QA4. I can replicate it easily at 2 of my clients, both of whom are running QA4 on Novell 3.12.' Interestingly enough, in my years of participating in forums, I do not recall this issue being raised prior to the release of version 5. Nevertheless, from my perspective, we have no way of knowing - at this point in time - whether this is a v4 problem, and/or a network problem and/or a 'flaw' in v5. The one thing we can be sure of is that it is currently a Q&A problem and that it occurs both in a network environment and on stand-alone PC's. In the database design that I tried to copy, I got inconsistent and 'strange' results every time I tried. Sometimes, my computer rebooted, sometimes it froze in Q&A and sometimes it froze with a completely black screen. I did find, however that when it froze in Q&A, it actually DID make a copy of the other databases (whereas it did NOT in the other instances). I found that I was able to run RECOVER on the new database and then COPY THAT DESIGN ONLY. So, in the 'new' database, the problem appears to be resolved. By copying the forms from the old to new database, I now have a 'healthy' version. Further examination of the 'bad' database revealed that the RETRIEVE SPEC of MANY reports had ASCII smiley faces; little o's with a French apostrophe over them such as •; little a's with an underscore beneath them such as ¦. When I copied and then tried to paste one of the characters, it drew me a picture of the screen. (Hey, I wish I could figure out how to do that when I want to). Another interesting observation is that some retrieve specs that appeared OK, changed - after looking at them a second time - to include those ASCII characters. This does NOT appear to be a problem that is peculiar to a network environment. However, with regard to ensuring that networks are set up properly, there is a wealth of information in this database (a search for 'network' will result in over 45 records). One that is particularly helpful is a Technical Application Note, 'Network Configuration Issues' which you can find by searching for NETWORK.TXT. (You can also download this file from the CompuServe forum). THE CAUSE: I do know that - in the past - sometimes an 'old' database contained a saved spec that interfered with Q&A's ability to copy the form design. Here's an example that was given. Let's say that when you created the database, one field was formatted as Text. You created a report with a TEXT value in the retrieve field (such as APP123). If you then customize the field by changing the format to (N)umber - but FAIL to change the retrieve spec in your report design (which you probably forgot ever existed) then, you might have problems copying the design. (The way to identify this type of problem would be to go back through each and every saved report and saved spec (retrieve specs, etc), and press F10 to find the offending data. I can tell you that I tried to replicate this type of scenario (in both versions 4 and 5) and couldn't. Naturally, the retrieve spec would NOT work and yielded strange results. In one case I got a Q&A message that said 'couldn't find 7/7/96' and in another case 'couldn't find goto.' In any event, it did NOT prevent me from copying the design of the database (along with the incorrect retrieve spec). So, as far as I'm concerned, I don't have a 'clue' as to the cause. THE SOLUTION: The GOOD news is that it is not that difficult to 'get around' this problem. Here are some solutions that HAVE worked: 1) In my case (when I was able to get a copy of the database) I found that by deleting the offending characters (or the whole retrieve spec or reports) I was then able to successfully copy my database. SO, it appears that the solution - in at least some cases - is to simply remove the 'corrupt data' from reports retrieve specs. In one case - where only one report was affected - I simply redesigned the report and that took care of it. There has been no further difficulty since. 2) Another Q&A'er has reported that their problem only occurred using Q&A's copy features (I don't know whether this is 'universal' or not). They resolved it by using the DOS copy command to copy the .DTF and .IDX files outside of Q&A. Then, they deleted all records (and ran recover to get rid of the dead space), leaving an empty database. If this works for you, make a copy of the new database (you should always keep an empty database on hand) and copy the records from the original database to the new. (Get RID of the original offending database and you should be rid of your problem). In both instances, the problem did not reoccur in the new database."," "," "," "," "," "," "," "," "," " "Duplicate; Duplicates; Record; Remove; Manual; Remove Duplicates; Case; sensitive; insenstive; case insensitive; case sensitive; removal; match; matching; exact; exact matching; D; DS; 1467"," ","What's the differences between D = Case Insensitive Duplicate Checks and DS = Case Sensitive Duplicate Checks in the File Menu/Remove? I am using QA 4 and I want to remove duplicate addresses. Again, I thank you for your help..........."," ",1467, ,"Jul 10, 1996","'Case' is referring to the type of letters you are using such as upper case (capital letters) or lower case (small letters). Case INsensitive will find a match regardless of whether any of the letters are upper or lower case. In other words if Q&A finds a record with a street address of 58-05 76th Street .... and another record with a street address of 58-05 76th STREET it will consider them a MATCH. If, however you select (DS) - Case SENSITIVE, the above example will NOT be considered a match. (BOTH addresses would have to read 58-05 76th Street OR 58-05 76th STREET in order to be considered a match). As a general rule, if you're looking for duplicate addresses, (D) - Case Insensitive, would be preferred. I hope this information is helpful. Good luck! **"," "," ","Q&A User Manual, Page 3-92"," "," "," "," "," "," " "Date;Dates;Next Date;Next Day;Next Calendar Day;New Date;New Day;Another Day; Another Date; Calendar; Add Records; Ditto; New Records; New Year; New Date; New Dates; Add Dates; 1468"," ","I would like to be able to set up a database for my to-do list with a seperate record for each day of the week, Monday through Saturday, and dates through the rest of the year. DOW is no problem, of course, but is there a quick way to add the records with the proper dates?"," ",1468, ,"Jul 18, 1996","There is a very easy way to add a years worth (or much more) of records into a database - in a HURRY and effortlessly. That is, providing you took my 'age old' advice of preparing multiple macros. By that I mean: Alt1 performs a function once Alt2 performs a function 10 times (by simply executing Alt1, 10 times) Alt3 performs a function 100 times (by simply executing Alt2, 10 times) & Alt4 performs a function 1000 times (by simply executing Alt3, 10 times) (If you would like more information on this technique, you'll find it - with a slight variation - in record #1038 of this database. In case I change the number, try searching with a keyword of MULTIPLE MACROS). A simple programming statement will take care of incrementing the date for you. You could use something like: <#10: if @add then {@ditto(#10); #10 = #10 +1} or <#1: if #10 = '' then {@ditto(#10); #10 = #10 +1} Add one record with your beginning date. While in the field, simply record a macro for ALT1 to simply press F10 ... and save the macro. Now, you can just press Alt 3 - 3 times Alt2 - 6 times .. and Alt1 - 4 times (13 keystrokes) and you have a whole years worth of records. (If you're lazy, like me, you can just press Alt3 - 4 times ... and you'll have some 'spare' records. After all, we must cut down on those keystrokes ). Since I already had my Alt1 through Alt4 macros established, the whole process took me LESS THAN ONE MINUTE. The programming was about 30 seconds and the 365 records were added in 7.33 (7 1/3) seconds. And, believe it or not, the more records you add , the more efficient the procedure becomes. I added 5 years worth of records in 26.44 (26 1/2) seconds."," ","In the first situation, each time you add a new record, Q&A will look at the number (e.g. 2032) and find a matching record, in the same data base, that is one number less (i.e. 2031). It will then take the date from that record (e.g. February 28, 1995), add '1' to it and put the resultant date (March 1, 1995) in the date field of the form you are currently adding. In the second situation, you would first have to determine the last date used ... such as by searching with ]max in the date field. Once you entered the date into the first record - of that particular add session - Q&A would then take over for you. This is very convenient when adding forms for a new calendar year, since you know to complete the first form as 1/1.","Date functions and programming can be found in the Applicaton Programming Tools Manual (APTM) on page 23, 26, and 30 through 33. Programming examples are given in Appendix A, Pages A-1 through A-4."," "," "," "," "," "," " "keyword; text; keyword vs text; text vs keyword; keyword/text; text/keyword; retrieve; retrieval; search; find; locate; &; ampersand; two; 2; two words; 2 words; word; value; 2 values; two values; 1469"," ","Since Q&A can search for data in any location in a field what criteria do you use to decide to make a field a Keyfield type? What are the things that you can do with a keyfield that you can't do on a text field?"," ",1469,37,"Jul 21, 1996","Keyword fields are not as significant as they were before we had programming in retrieve specs and some of the later enhancements to Q&A. Nevertheless, there are still some distinctions between keyword and text fields that make their use worthwhile. While it's true that 'Q&A can search for data in any location in a field,' using keywords can sometimes make retrieval much easier, simply by eliminating the need for the use of 'wildcards'. (I would say that this is one of two primary differences). If someone were looking for the record of Buckman it would be common for them to type: buckman and not so common for them to type: ..buckman.. Take, for example, the recording of a persons job skills. Your field might look like: JOB SKILLS: Typing; Stenography; Reception; Computer If you want to find a receptionist who is familiar with computers would you rather type: &..computer..;..reception.. (as you would do in a text field) or &computer;reception (as you would do in a keyword field) (By the way, the User Manual illustrates the use of the ampersand (pg 3-51) but mistakenly includes it in the group that pertains to keyword only. You can use the ampersand in a text retrieval as well, to indicate that both values must be present). There is one invaluable use of keyword fields that I wouldn't trade for anything. You see it in the Q&Answerman database (it's the way you look for records) and I've gotten in the habit of using it in most of the databases I create. I frequently make the first field of a database a 'FIND' field. I have the cursor bypass this field when adding or searching records. The field is formatted as keyword and programming automatically fills the field. Typically, I use a person's last name, phone number, account number, etc. etc. (according to the use of the database). Now when someone wants to find a record they can put their criteria in the ONE field (without having to tab all over the form), they don't have to remember how to use wild cards AND only ONE speedy field is needed for typical searches, instead of many. It works like a charm and users love it! The second primary difference is that you can create a report sorted by each of the values in a keyword field (a keyword report) which is something you cannot do with a text field. In the example I gave above, you could generate a report that would show: Computer Mary Bob Reception Frank Helen Stenography John Mary Typing Alice Bob While you might be able to replicate this from a text field (in some cases), it would take a bit of doing. All it takes in a keyword field is making it the first column and adding the letter K e.g. 1,K If you like, you can print an example of a keyword report from this database. (There's no way you could replicate this from a text field; it's 'humongous.') Another record in this database, identified as XRef #37 makes use of a keyword field to print varying numbers of labels - depending on the needs of individual records - from within the same database."," "," ","There are several references to Keywords in the User Manual. They are defined on pages 3-14 - 3-15, retrieval is illustrated on page 3-56, and columnar reports are discussed beginning on page 4-9."," "," "," "," "," "," " "delete; deletion; key word; keyword; keyword field; key word field; delete; remove; remove value; value; word; words; 1470"," ","I need, on a recurring basis, to remove a name from a keyword field, using mass update. Right now I am selecting that name in the retrieve spec and entering an update spec of: #1=@del(#1,@instr(#1,'Harrison'),@len('Harrison')) While this works, it does leave extra semicolons in the fields, and cannot be easily turned into a macro since it requires typing the name in three times. Is there some way I can automate this to make it easy for a typist to enter the name once and have it removed from all records?"," ",1470, ,"Jul 21, 1996","You certainly can, and you were right to think of macros. Two saved specs, an auxiliary database and a procedure wrapped in a macro will do it nicely. Put it on the menu as an alternate selection and it can all be done with one keystroke ... and the entry (once) of the name to be removed. Since you seem familiar with programming, I will point out the major steps. If you need more detailed info on any aspect of the procedure, you should be able to find it in other records in this database. First, create an auxiliary database; let's call it LOOKUP.DTF. It only needs to have two fields: RID: (formatted as (N)umber) and NAME: (formatted as (T)ext). Make the RID field speedy. Add one record and enter, in the RID field, the value 9999. If you like, program it (in v5) so that if someone tries to add a record, Q&A will automatically exit from add mode. Next create the specs needed for the retrieval and the mass update. While it will NOT hurt to have extra semicolons in the field, we might as well remove them, too, since the programming only needs to be done once. In order to remove the semicolons, we will need to be concerned with (1) whether the name was entered with a semicolon and NO space before the next entry, (2) whether the name is in the first or middle portion of the field and (3) whether the name is the last entry. Your retrieve spec would look something like: {@xlu('lookup',9999,'rid','name')+';'}; {'; ' + @xlu('lookup',9999,'rid','name')}; {';' + @xlu('lookup',9999,'rid','name')}; {@xlu('lookup',9999,'rid','name')}; and your mass update spec would look something like: #1 = @replace(#1,@xlu('lookup',9999,'rid','name')+'; ',' ); #1 = @replace(#1,@xlu('lookup',9999,'rid','name')+';',' ); #1 = @replace(#1,'; '+@xlu('lookup',9999,'rid','name'),' ); #1 = @replace(#1,';'+@xlu('lookup',9999,'rid','name'),' ); #1 = @replace(#1,@xlu('lookup',9999,'rid','name'),' ) Now, all you have to do is record your macro and add it to the main menu. The macro would retrieve the form from the LOOKUP.DTF, go to the NAME field and pause (Alt/F2) for the clerk to enter the name. The macro would then proceed to MASS UPDATE the database containing the name field, calling up the saved retrieve and merge specs. That's it. The clerk will select the menu item, enter the name, and the job is done. (Please note that while you can change the programming sequence of the retrieve spec, you SHOULD NOT change the sequence in the mass update spec. It must be done methodically to remove names in all possible combinations)."," "," "," "," "," "," "," "," "," " "keyword; key word; keyword field; key word field; post; posting; post spec; posting spec; spec; 1471"," ","I am trying to post using a keyword field as the destination key field and am not getting the desired results. The source dtf seems to be reading the key field in the destination database literally (i.e., including the semicolons) instead of individual values (between the semicolons). Is there something special I have to do to accomplish this, or is Q&A simply not able to discern the individual values for purposes of posting?"," ",1471, ,"Jul 21, 1996","I have, in the past, attempted to do posting involving (one of several words in) a key-word field and simply concluded that it cannot be done. (Although, I've concluded this for myself, I've never actually found anything in the manual that specifically addressed the question). I have, however worked on a project where I needed to post FROM a key-word field. What I decided to do was to have all entries placed into one field and then used programming to automatically separate them into separate fields, from which I did the posting. Perhaps you could do something comparable in the destination database. I do hope that this solution is something that would work as well for you. Good luck!"," "," "," "," "," "," "," "," "," " "menu; custom; custom menu; custom menus; menus; macro; macros; wait; pause; print; printing; screen; printer; option; choice; select; selection; make selection; report; preview; 1472"," ","So I've built this great custom menu structure. But now I'm having a problem that I can't seem to solve. One of my menus calls for the printing of several reports. While I've designed these reports to print to the printer, there is no problem..the report prints and the macro returns to the designated menu. My problem is: How do I utilize this same macro so that it pauses on the print options screen and allows me to choose between printing to the printer or printing to the screen? When I build in a 'wait' on that screen, and then direct it to print to the screen, the report prints but then quickly disappears and is replaced by the return menu. How can I build the macro to allow me to see the report on screen, if I so choose, scroll it, move up or down a page, and THEN go to the return menu when I'm finished? Is this possible?"," ",1472, ,"Jul 21, 1996","All you need to do is add another 'pause' so that the report can be viewed on the screen. (When you print the report to the printer, you may have to press enter one additional time, but that should be a fair trade-off). Simply (W)rite, (G)et your QAMACRO.ASC (or other macro) file and search for the macro in question. Within the macro, you should see something like: .. rpSOMEFILESOMEREPORTy .. Right after '' is where you should insert another pause, which you can type manually as . (You can, of course, change the to if you prefer to use f10 to resume the macro). Then simply save (Ctrl/F8) the macro file and retrieve it (Shift/F2, (G)et macros (filename)) to try it out. It should do the trick."," "," "," "," "," "," "," "," "," " "report; reports; heading; headings; X-tab; Cross Tab; Crosstab; No entry; blank; blanks; 1473"," ","I have a field that is used in a crosstab report in v 4.0 that could use a heading. During data entry, the field, called Disp., allows one of 11 options. These options comprise the column headings. Choices 1-10 all have exact wordings (e.g. 1-age, 2-health, 3-behavior, etc...). The 11th choice, is to leave it blank. By leaving the field blank, it indicates that there is no dispositon of the client as yet. In the crosstab report, each of the headings dutifully print out (yeah! :-)) But there is no heading for the 'blank' undecideds. I could leave out the 'unknowns' but the report is of much more use with them in it. Is there a way that I can put a column heading on this field during printing?"," ",1473, ,"Jul 25, 1996","We're talking Q&A here, right? Right! Then, of course, it can be done. In your Cross Tab Spec, simply number your Disp. field, e.g. DISP: #10 (Enter your Row and Sum fields as you normally would) Then, in your Derived Fields (F8), enter: Heading: Disposition Formula No. 1 @txt(#10='','Undecided')+@txt(#10>'',#10) Cross tab spec: COL That should do it, very nicely."," "," "," "," "," "," "," "," "," "