Humour: was Re: Conversions
In a message dated 4/2/2004 10:06:39 PM Pacific Standard Time, [EMAIL PROTECTED] writes: Tony, Stupid question... If you and I built a company which was strictly Hey my name's not Tony but if there's money involved you can call me anything you want. Will -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: Conversions
Thanks to all who have provide some good ideas. The conversion has occurred and is in the growing pains. Still a mistmatch but there's no going back. Perhaps I'll take this approach to learn Crystal Reports or MS Access reports. There are many previous reports and downloads that can't possibly come from these wizard oriented facilities and I will have to re-create them using their tools. One question. Many of the MV reports that I've created were consolidations of multiple sales/customer/product files into concise reports. They enlist databasic to create a temp file and populate it with the report-related sub-categories that don't consolidate easily in MVQuery. Thus the temp file is then query-able. I've been told that Crystal Reports doesn't allow for the creation of temp tables while Access can. Is this true and should I develop their replacement reports in Access. One strange thought occurred to me that may not fly. Export all the sales/customer/product data back to the MV system and use the existing reports. At least they're already tested finished. Thanks again. - Original Message - From: Dawn M. Wolthuis [EMAIL PROTECTED] To: 'U2 Users Discussion List' [EMAIL PROTECTED] Sent: Saturday, April 03, 2004 9:50 AM Subject: RE: Conversions Mark -- I don't have experience with Great Plains, but can definitely sympathize with your situation. I have been on both the technical and management side of such conversions. Given that it sounds like the decision has been made, money has been spent, and work has been done, you could tackle it by coming through with a this is how we COULD accomplish what is desired set of chats and formal meetings. --Document (if it isn't already) precisely what the goals are for the implementation of the new software so that it is clear what needs to be accomplished from the perspective of Bob the owner. Include goals of what we don't want to impact and not just what we do want to change (for example, is a negative impact on profitability acceptable for 1 year, 2 years?) --Collect all issues/concerns that those in the trenches have related to this project; back these up with metrics/facts where you can --Ask this same trenches group how they think these obstacles can be removed or mitigated --Discuss the issues and possible solutions with mid/upper management and request their brainstorming as well on how to mitigate the concerns --Interview other Great Plains users and ask them how they addressed similar issues --Prepare a report (put in writing in some format, perhaps ppt) that has the angle of how we can accomplish this and does not have an underlying tone to indicate that you disagree with the decision to move forward with this software. The report can still indicate that there are costs to the conversion and perhaps even that there were unanticipated costs that were found once those who work with the software became familiar with the software --Work with all parties to choose the approaches for handling the obstacles in the path of a successful conversion and then implement those. Of course, it is never as easy as following bullet points. I would also suggest having a good inventory of those with whom you have a good working relationship and build on those relationships to help the project run smoothly to completion. Best wishes. --dawn Dawn M. Wolthuis Tincat Group, Inc. www.tincat-group.com Take and give some delight today. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson Sent: Friday, April 02, 2004 10:05 PM To: U2 Users Discussion List Subject: Conversions Does anyone have a short paper on the care and feeding of both the company and its employees during a conversion/migration from one system to another. I'm facilitating a migration from MV/Results/Primac to Great Plains and it is a very large mismatch. GP seems to be shopping-cart oriented and Results/Primac are more of a traditional Order Entry system. I can't seem to convey that difference as management (read: those who don't use the computer) like the GUI and all of the nice links and screens. The worker bees are in a turmoil with the increased amount of carpal-tunnel potential mouse/keyboard back and forth as well as the absense of many functions that were present under the MV app. Their productivity has fallen 75% as it takes 4x longer to enter an order. There are no sales tax lookups, no product or customer lookups. You clearly cannot scroll through 35,000 line items. There's no easy alternate shipping addresses and the original reports leave a lot to be desired. The accounting package is appealing but a company doesn't exist just for the accounting dept. Not to mention all the hamburger-helper features i've installed over the last 6.5 years. I also have to fabricate custom reports with Crystal Reports and/or Access as there are many fields of data that should be there like customer back orders, sample customers, customer
Re: Conversions
Mark, Tell them you are re-purposing the old MV system as a data warehouse as a cost savings measure. That they'll understand and hopefully appreciate. Then do what you suggested: One strange thought occurred to me that may not fly. Export all the sales/customer/product data back to the MV system and use the existing reports. At least they're already tested finished. Because that's the first step in creating a serious data warehouse. -- Sincerely, Charles Barouch www.KeyAlly.com [EMAIL PROTECTED] -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: Modern Universe (TESTING)
One thing I think everyone's missed (deliberately or otherwise) was that Sara's original post had a constraint with a LEADING wildcard (WHERE address LIKE '%EXPLORATION'). The argument that has been raging since has used examples with TRAILING wildcards (WHERE name LIKE 'Sara%'). Apples and oranges, folks, especially if B-tree indexes are involved. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: Modern Universe (TESTING)
Joe, The example you specified (below) is case-SENSITIVE. It will only return rows where the value begins with the four upper-case letters designated. In particular, it will not produce the results you showed (and could never select the row with SARRA). Your query is identical to the SQL: SELECT fieldname FROM filename WHERE fieldname LIKE 'SARA%'; My techniques showed how to render this into a case-insensitive search by performing on-the-fly conversion to upper-case. It would be just as valid to perform on-the-fly conversion to lower case. However, this conversion is done in the WHERE clause, not in the SELECT clause (or in the RetrieVe equivalents), so that the data values are displayed in whatever case they are stored. Regards Ray - Original Message - From: Joe Eugene [EMAIL PROTECTED] Date: Wed, 31 Mar 2004 16:37:54 -0500 To: U2 Users Discussion List [EMAIL PROTECTED] Subject: RE: Modern Universe (TESTING) Ray, I see you are doing a few things here, am not quite sure i understand. The only way i have OUR UV Programmers using BASIC/PICK do this is like SELECT [FILENAME] WITH [FIELDNAME] LIKE 'SARA]' (NOTE **]* - Syntax might a bit OFF) Something like the above produces a CASE-INSENSITIVE Search and returns all the below Sara sarra saRraA etc. The UPCASE and LOWCASE only Returns those results right? So in your Experience, would you say SQL Interface is Faster than any other Interface within UV? Thanks, Joe Eugene -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ray Wurlod Sent: Wednesday, March 31, 2004 3:57 PM To: U2 Users Discussion List Subject: RE: Modern Universe (TESTING) On this basis here are the RetrieVe equivalents for my earlier post. The main difference is that there's more than one verb (for different query result formats) and the selection criterion begins with the keyword WITH rather than WHERE. And the pattern matching specifiers are different (for example ... rather than % for multi-character wildcard). verb PEOPLE NAME WITH NAME CONV MCU LIKE SARA... verb PEOPLE NAME WITH EVAL UPCASE(NAME) LIKE SARA... verb PEOPLE NAME WITH EVAL OCONV(NAME) LIKE SARA... verb PEOPLE NAME WITH EVAL UPCASE(LEFT(NAME)) = SARA where verb can be any of: LIST SORTcolumnar report SELECTSSELECT Select List LIST.ITEM SORT.ITEM raw format LIST.LABELSORT.LABEL mailing labels REFORMAT SREFORMAT target is second file/table COUNT SUM not really relevant for NAME HTH - Original Message - From: Joe Eugene [EMAIL PROTECTED] Date: Wed, 31 Mar 2004 15:33:20 -0500 To: U2 Users Discussion List [EMAIL PROTECTED] Subject: RE: Modern Universe (TESTING) Tim, My apologies... Yes, i know UV has a SQL Interface but i didnt think many UV Programmers used this Interface... As a matter of Fact, i like the UV SQL Interface. I have a PE Edition of UV on all my machines and i have only used the SQL Interface within UV. In our UV Shop, UV Guys are NOT supposed to use this SQL Interface as they claim its very slow than using the Native SELECT WITH . I have read the UV Manual that reflects RDBMS, this manual explains you can setup Tables Exactly like any RDBMS using Data Types (Varchar, char, Int etc) All the the testing i have done does NOT involve using the SQL Interface in UV, Our UV Shop uses FILE Types, NOT RDBMS Tables and we use PICK/BASIC/REDBACK to Interfact with these FILES. Perhaps the problem might be our UV Shop using PICK/BASIC... Maybe the SQL Interface on UV is much faster. I dont know. Thanks, Joe Eugene From: [EMAIL PROTECTED] on behalf of Timothy Snyder Sent: Wed 3/31/2004 3:12 PM To: U2 Users Discussion List Subject: RE: Modern Universe (TESTING) Joe Eugene wrote on 03/31/2004 02:59:29 PM: Please post your PICK/BASIC and SQL Query.. so we i can learn the magic you did on the PICK Side. Joe, Unless I'm missing something, Sara used the SQL statement against the UniVerse database. Perhaps you weren't aware that UniVerse supports SQL statements to query the database. I don't think she used any magic. Therefore, in her original post, she provided all the information you need to do a comparison. Also, you keep referencing PICK/BASIC. BASIC is the programming language, not the query language. There is also a native query language, but that's only one of many ways to access the database. I hope this helps to clarify your expectations. Tim Snyder IBM Data Management Solutions Consulting I/T Specialist , U2 Professional Services Office (717) 545-6403 (rolls to cell phone) [EMAIL PROTECTED] -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing
