Anyone update from 7.6.300 to 7.6.300B? 1

[ultrav]

Any problems? Issues? Do we have to install 7.6.300a first or does b include everything from a?

Thanks
Celeste

 

[dgillz]

B is all inclusive, no need to update to A first. I know several people who have updated with no major issues. However this does not mean you will not have any.

Is there some reason you are looking to upgrade? In general I do not advocate aggressive upgrading unless there is a specific fix in service pack B that you need.

Software Sales, Training, Implementation and Support for Macola, eSynergy, and Crystal Reports

http://www.gainfocus.biz

 

[ultrav]

I am having form issues that appear to be fixed in b (picking tickets that don't print if they have 6 line items - if we put in comments to push past the end of the form it works). Now I am having issues with invoices that are running to two pages(dropping line items) - was hoping it would be fixed also. There are a few other fixes that would affect us also.

 

[dgillz]

In that case I would go for it.

Software Sales, Training, Implementation and Support for Macola, eSynergy, and Crystal Reports

http://www.gainfocus.biz

 

[SusanD5320]

We upgraded about six weeks ago. A few of the major issues we've run into....

PWE - Users that have customized/restricted menu access are unable to get some tasks to run. Current solution is to log in to SQL Explorer to access those menu options.

AP - Editing a distribution line on a voucher matched to a PO receiver causes the Invoiced Amt and Qty to double in error on the PO. Basically, you have to do it right the first time. This will cause Received Not Invoiced to show the PO's as over-invoiced. If you balance to this report to the ledger it won't match. Supposedly there's a patch but we've installed and it didn't fix the error.

OE - New feature to print immediate pick tickets. Using this does not update the order header status to 4.

AR/OE - Attempting to reverse a check posted thru OE cash displays message that A/R account is not on file. Answering yes attempts to add the account but still displays the message. Answering no displays the message again. Endless loop.

We definitely will be a bit more patient and let someone else find bugs when 'c' and 'd' come out.

 

[NEmacGuy]

There are two version of B a pre-5/25 and a 5/25 version of B. If you have the pre-5/25 version. Throw it out.
There was a bug that if you maintance date was OK coming due soon, you got turned off ??? Plus something that you could download.

 

[NEmacGuy]

I would also look at the list of bugs, and bugs fixed in C before loading B, and see if any would stop you from going forward. To date we have received approx 7 patches for mostly OE views and the MS layer. They will always be bugs. I would have to say, thing have been pretty good lately. Our accounts that had major issues in B, got patches in about a week or less.

 

[OTSUPPORT]

I have ten years of systems administration under my belt before I started dealing with Macola a year ago when I was hired here. I moved here from Boston where I was a field engineer supporting accounting systems and networked hardware for 173 clients inside the I495 belt.

Sooo... we upgraded from 7.6.100a to 7.6.300b and did a pervasive to SQL upgrade at the same time. We had two Exact consultant's onsite performing the entire procedure. This was on June 13th; with the latest ISO of 7.6.300b obtained the week before go live.

CUSTOM FLEX AND 7.6.300b
Initially it showed promise, we had some problems with our custom flex scripting which took over a month to get fixed; we had product going out the door the wrong price. The replaced the custom flex code in our live system three times before it did what it was supposed to do with out massive crashes. For the first two weeks, system speed was okay, after one of the Flex code replacements, all of the sudden all of our OE screens were taking between 43 - 80+ seconds to open. Now all of the sudden to fix this problem we needed a newer version of Flex then the one that was sent to us with 7.6.300 SQL when we initiated the upgrade. On all computers we had to go around uninstall flex, search for some 30 registry entries and delete, then reinstall this latest version with reboots in-between each per Exact's Engineer's instruction to their consultant. This relates to custom FLEX code, Flexibility, and 7.6.300b, I know many others have custom mods, something to be aware of. Now OE takes around 14 seconds to open across the board on P4/512RAM computers.

During the upgrade, for those doing reports or anything more than 5 pages, requires two registry modification made to each computer, you also have to mod the reg files in 6 places because they contain HOST name, or the name of the local computer you are installing it on. This was required on most computers, if not, more than 5 pages took more than 5 min. So we are up to having to modify the registry 4 times just to make it work faster then a turtle. Did I mention Macola is the only application running on a P4 dual Xeon with U320 SCSI Cheetah drives in a Raid10 config? (STRIPE + MIRROR / 4 physical drives = 1 logical) Stress test on SQL 32 passes resulted in averages of 50 - 60 megs a second transfer with in SQL of data chunks ranging from 32k to 4096mb resu8lting is 5835 writes a second. We have around 35 active users, which may account for 20 writes a second? (second/not minute)

log snippet.
Simulating CheckPoint of 19970 pages like SQL Sever 8.0
CheckPoint wrote 19970 buffers in 3422ms Writes/Sec = 5835.768556 Saturation: 0 Time per I/O: 0.171357ms
CheckPoint Total I/O time: 6970ms Avg Latch Time: 0.349024ms Smallest: 0ms Longest: 16ms

Okay so current on going problems we still have as of 7/28/05 which is 7 weeks after our Go Live. All of which Exact software, our Account manager, two consultants, two coders have been aware of since we were aware of them.

Postings of Subledgers currently take almost 6 hours to complete.

OE Consolidated view displays incorrect information. According to Exact, KNOWN BUG

Orders and RMAs dupe numbers if they are being entered by two people, on two different computers at the same time. reproducible by Exact (Source Code, NOT custom code) We have to do all our RMAs before the day starts with no one else in the system.

Crashes, we get COBOL and VB crashes 5 - 10 times a day across different users, computers, permissions, and modules. We run other networked applications as well which are instant.

The catalytic reason we start this entire upgrade was because of the Peak Data mod causing incorrectly attached data to the wrong customers. I have a Crystal Report created by Exact consultant that I run to check for these, well guess what ... I have 5 as of yesterday with order dates this month in July, meaning the system is still doing it with out Peak Data mods.

Sooo ... if you have custom Flex code and are thinking of upgrading ... good luck.

-T

 

[kscheeler]

OTSUPPORT

It sounds like you moved to a new server when upgrading from Btrieve to SQL. Your slowness on screen loads probably first started when you shut down your old Btrieve server. I have clients "remove" Macola by deleting the registry key HKLM\Software\Macola, deleting the folder c:\program files\common files\macola shared, rebooting and then reinstalling Macola and Flex. That's usually done the trick with the clients that I've moved servers for.

14 seconds for the order entry screen load sounds high for the server and clients you are using but the flex code could be loading things at startup on that screen. Flex could also be still looking for something on the old server that was missed in the registy editing. One thing to test is a machine that never had Macola on it in the first place to see how it does with a fresh install.

You don't mention how long the subledger posting took in Btrieve but I'm sure it was less than 6 hrs. I have seen posting take longer in SQL than in Btrieve. Overall, the various applications run as fast or faster in SQL than in Btrieve but there are certain ones that can take longer. Purging AR open items is another one. I would look at either posting more frequently, doing one application at a time to see which one is taking up most of the time and also purging the distribution file.

You mention various bugs in 7.6.300b. SusanD5320 mentioned some earlier in this thread. I would have to say that bugs get more attention and get fix faster than they did in the past. When Exact changed the compiler in 7.6.200+ and switched to a few thousand dll's it became easier to patch a specific bug by simply replacing one or two dll's. I would ask for a patch if you haven't already. If one's available and with the frustrations you've had, I think someone at Exact should be able to help you.

I would need more information about the VB and COBOL crashes that are occuring. Not that all of the information is easy to understand but Macola creates a log file in the macsql folder when a crash occurs. Usually by user name. It wll give you insite into who's getting the crashes and to see if it's similar information in the log report.

I think your last statment is misleading based on what you wrote however. You didn't upgrade any flex code, you went from having Peak's enhancement (which is modified source code, quite different from flex code) to reworking the enhancement in flexibility. It sounds like the flex code needs some tweaks to get things right. Coding in flex can sometimes be difficult because you CANNOT change Macola's internal logic. Al you can do is undo and redo things after the fact.

Flex code should upgrade to a new version without any problems.

The only times I've had to export and reimport flex code was going to 7.5.102c and 7.6.100. In both cases, there were alot of changes in the program, new functions added, function call changes that would break some flex code.

 

[OTSUPPORT]

Hiyas Kscheeler,

"It sounds like you moved to a new server ...snip... I have clients "remove" Macola by deleting the registry key HKLM\Software\Macola, deleting the folder c:\program files\common files\macola shared, rebooting and then reinstalling Macola and Flex."

Yes this is a new server. My issue is that the system was not this slow directly after the upgrade, maybe 6 or 7 secs tops for the OE screen. Three weeks later and a custom flex code changes later, is when it went to 60sec. Deleting the reg entries and common files, then installing the latest version of Flexibility brought it down from 60 secs to 14 secs. I have gone as far as to format and start from scratch with a client, same results.


".... I would look at either posting more frequently, doing one application at a time to see which one is taking up most of the time and also purging the distribution file."

We post once a day, it's a sad day when an accounting system cannot handle that. IM takes the longest on individual subledger postings, and distributuin has been purged and rebuilt. Exact support instructed me to use some duct tape and bubble gum, after which total subledger postings time is at about 2 1/2 hours as of today, in Btrieve it took less then 30 min.


"If one's available and with the frustrations you've had, I think someone at Exact should be able to help you."

Yes, I have escalated this to someone who reports to Jim Kent, VP NA. Actually Exact wasnt doing a whole lot for me until Lisa got envolved. Consultants were great, they were just getting the short end of the stick becuase what they submitted wasn't being addressed.

As far as the VB/COBOL errors, I am actually forwarding them to Exact as my users forward them to me with what they were doing, the logs and screen shot of the error. I find that my crashes are happening mostly in accounting.

Apologies for the last statement being misleading, I meant upgrading from 7.6.X to 7.6.300B when you have a flex enhancement becuase you will be using Flexibitly which I appearantly am having severe issues with.

Macola with out flex on any system here runs fine. Yes, I know it's in the code, but considering the code does what it is supposed to be doing finally, it is doubtful they are going to put much effort into making it faster.

I actually don't touch the Flex code, I let the consultants do it this way, they can't say I did anything wrong. Thank you for your input!

-T

 

[kscheeler]

How many records do you have in the IM distribution file. You can run the following query in Query Analyzer to find out.

select count(*) from imdisfil_sql

You can also rebuild your indexes in Query Analyzer. I would do this for the inventory files

Copy the following code into query analyzer

------------------------------------------------------
--This function does a rebuild on the tables selected. If you do not designate a
--specific index, it will rebuild all of them.

--Change the database from demodata to your live company before running
use demodata


--Inventory Management Tables
dbcc dbreindex (imitmidx_sql, '', 80)
go
dbcc dbreindex (iminvloc_sql, '', 80)
go
dbcc dbreindex (imlocfil_sql, '', 80)
go
dbcc dbreindex (iminvbin_sql, '', 80)
go
dbcc dbreindex (imlsmst_sql, '', 80)
go
dbcc dbreindex (immatcst_sql, '', 80)
go
dbcc dbreindex (imitmnot_sql, '', 80)
go
dbcc dbreindex (imcatfil_sql, '', 80)
go
dbcc dbreindex (imitmadt_sql, '', 80)
go
dbcc dbreindex (iminvaud_sql, '', 80)
go
dbcc dbreindex (iminvhst_sql, '', 80)
go
dbcc dbreindex (imlstrx_sql, '', 80)
go
dbcc dbreindex (imbintrx_sql, '', 80)
go
dbcc dbreindex (imtyploc_sql, '', 80)
go
dbcc dbreindex (imitmtxt_sql, '', 80)
go
dbcc dbreindex (iminvtrx_sql, '', 80)
go
dbcc dbreindex (imdisfil_sql, '', 80)
go
dbcc dbreindex (imtagfil_sql, '', 80)
go
dbcc dbreindex (imtaghst_sql, '', 80)
go
dbcc dbreindex (imordbld_sql, '', 80)
go
dbcc dbreindex (imordhst_sql, '', 80)
go
dbcc dbreindex (imrechst_sql, '', 80)
go
---------------------------------------------------

 

[OTSUPPORT]

Hiyas Kscheeler,

I'm impressed, it took Exact weeks to suggest the same things you have in a couple of post.

I have 2,630,379 records in my IMDISFIL_SQL which has been purged upto 12/31/2003. Yes, that is a lot but since MS SQL max database size is 64 petabytes, I don't see how that could be a problem.

I did have a MSLsyscheck, does that do the same thing?

If not, what is that syntax?

TABLE NAME, (what goes here), (what is 80)

Thank you for taking the time.

-T

 

[kscheeler]

It's not that SQL can or can't store a certain amount of data, it's how Macola reads and uses that data that will make the system fast or slow. I will try to prove it today or tomorrow but I believe the post from sub ledger is scanning the entire table and not just the records that are within the date range that you are posting. Macola scans the records first to validate that the account numbers that might post are valid and exist in the system account table (SYACTFIL_SQL).

I'm actually going to a client today that I'm testing the BTR to SQL upgrade (15GB total database size) which has 3.5 million records in their MCA distribution table and it currently takes about 2 to 2.5 hrs to post (weekly) in Btrieve.

The MSLSysCheck program compares the tables and index structures from the MSL files against the actual tables in a database. The MSL files are where Macola stores the structure of each table. If you create a new company, that's where Macola goes to get the information to initialize the tables.

The DBREINDEX function however rebuilds the indexes that are on the tables

The syntax for the DBCC DBREINDEX command is as follows:

DBCC DBREINDEX (table_name , index_name , fillfactor)

fillfactor

Is the percentage of space on each index page to be used for storing data when the index is created. fillfactor replaces the original fillfactor as the new default for the index and for any other nonclustered indexes rebuilt because a clustered index is rebuilt. When fillfactor is 0, DBCC DBREINDEX uses the original fillfactor specified when the index was created

If you leave the index_name blank '', then it will rebuild all of the indexes.

 

[kscheeler]

UPDATE,

I did a post from subledger on the MCA distributions of about 6000 records of about 40000 for the date range. The whole process between scanning and posting took about 15 minutes. Granted, I'm the only one on a seperate network where we are testing the Macola upgrade.

I ran a SQL profile on the user I was posting from and found that it didn't seem to be actually scanning every record in the database. It was writing records to a work table (MCGENWRK_SQL) or (IMGENWRK_SQL for IM distributions). It also wrote and deleted records from the msllockdb database and read and updated the GLCTLFIL_SQL table for the next transaction id number.

As a note, my client is posting to the GL general journal file which then has to be posted within the GL vs. posting directly to the GL trx table.

I'll have to see what else may be causing the time difference.

Also, do you post in summary or detail?

 

[NEmacGuy]

I have been told that at least for Progression that the system is still optimized for btrieve. That is transactional data vs relational data. When the system is looking for the records in the distibution to gl file, instead of sending a (select where dist_dt <=> date) it send multiple individual prepared SQL statements. We had one analyst look at a tax analysis report that was extremely slow, and he advised not to run during normal business. It killed the server. The post from sub-ledgers are also a slower.

OTSUPPORT - you mentioned the MSLChecker utility.
You absolutly should run this. I have run this utility for every single btreive to SQL conversion. If whoever ran your conversion didn't, they were a little sloppy. It is also part of Exact Macola SQL performance tech-note's
01.533.826 and 02.017.030. In addition to those I would check how big is your Temp.db and its log file. I changed one clients from (100 meg 25 meg log) to (250meg 50 meg log) and he saw drastic speed improvements.

 

[kscheeler]

Microsoft recommends that a log file be between 25% and 35% of your database size depending on the number of transactions you are doing. For a 4GB database, you are looking at a 1GB to 1.35GB log file. A largely historical database probably doesn't warrant a log file that size but maybe somewhere in the 15% to 20% range.

 

[OTSUPPORT]

When we post we post in Detail.

At the moment I have a few things I am trying over this weekend and will update. I also thank you all for your input, it's good to be talking to people who understand what they are doing.

-T