Share
ReportIs there an easy way to increase the field length without screwing up the customer table.
Thanks
Kevin
*This post is locked for comments
You’re offline. This is a read only version of the page.
455
Is there an easy way to increase the field length without screwing up the customer table.
Thanks
Kevin
*This post is locked for comments
A few additional comments:
The migration from version 2.x to later versions was a substantial change, and could be very involved depending on the quality of the data as I'm sure you found out. The upgrade from 6.5 to 7 will be much easier for you. 2.x to later required all of the data to be migrated from a different schema, along with a database platform change from bTrieve to MS SQL. It's probably not a good comparison when gauging the level of effort to move to 7.
That said, the major change from 6.5 to 7 is the change of the screen code from VB6 to VB.net managed code (highly recommended), the availability of SQL Reporting Services for reports, and a different parent user interface (screen layouts are mostly unchanged). If you have any custom screens that were written for 6.5 in VBTools, they will need to be run through the visual basic conversion utility to upgrade them to .net code. Sometimes there is some manual development work involved if the conversion utility encounters code that isn't 'standard' for an SL screeen, such as file or registry access, custom data libraries, custom controls, etc.
Paul
You'd be robbing yourself if you didn't at least check it out in your test environment.
It's a good choice especially because it's Windows 7 compatible, and soon that's all you will be able to get on workstations.
When we converted from Solomn 2.04 to SL 6.5 in Nov 2007 they actually left the 7.0 disk to Upgrade in the future but there was a whole process converting OM and our customizations. I may have to build another server and run some tests on an off-production server before we go ahead.
Thanks
I have been the Sysadmin for our company and have been using Solomon from the old 1.4 Netware days. This new version sounds like a good choice.
No, ALL the address fields are larger. If you have international addresses, or just need more room for longer names, that's a plus.
And the BIGGEST things that people like seem small: Editing a field now inserts rather than overwriting, and you can SORT on nearly all grid screens. (If a vendor says, did you pay my invoice xxxx, you can sort in the documents tab of Vendor maint on vendor invoice number, for example. Or by date)
And they added more things you can email (I'm not sure what... haven't dealt with that yet)
Note that this assumes you went to the FEATURE PACK. The FP is the equivalent of version 7.5 in the old terminology. It is much more than a service pack.
Schweet! Now I don't need to do my contortionist test using global address book. I was so looking forward to it...
And you made ME curiouis... so I checked SL7 FP1 (where the address fields are increased)
The email field is now 80 characters!
You made me curious, so I just checked v7 and it's still 30 characters. I have an idea I'd like to test. What about creating a contact record for the customer in the Exchange Global Address Book and setting their Alias value to their customer number or something short? Then put the customer # in the e-mail address field. I don't know if the Exchange Global Address book is available to the sending application for alias resolution, but it might be worth a try.
ISIS software has a product called Expanded Master Information that provides you with 75 fields (dates, values, characters) that you may be interested in. Some of the character fields can be made at least 50 characters long. I've used this for the way you've described so that the email address would fit.
Of course you'll also have to modify any reports that would need this information as well.
Brian Kuehl
ePartners, Inc.
#1
André Arnaud de Cal...
291,391
Super User 2024 Season 2
#2
Martin Dráb
230,445
Most Valuable Professional
#3
nmaenpaa
101,156
All responses (
Answers (
