7 replies to this topic

[Lewis Mccabe]

Hello All,

I see that version 6.2 is in production. Darren says some large customers are live. Can you 6.2 guys give us some feedback? Thanks.

Lew

[Ross Bevin]

Hi Lew,

I was one of the beta customers. I did some major testing from December until now. I'm in a unique situation where we are planning a new look and feel for our system and wanted to work with the new features. I logged quite a few bugs during this time but am happy to report they were fixed expeditiously. There are still a couple of cosmetic bugs to fix but I'm sure they will be fixed soon. I have to say that 6.2.16.0 is very stable. Being able to use the full screen for Developer is a huge plus. My favourite new features are Active Paging, where you can click in and out of a parent and it's child paging screen. I also like the Multi-Select List Boxes and Single-Click Event. By and large this is a good release and I would encourage you to migrate to it.

I will be migrating our production environment to 6.2 from 6.1 in approximately 4 weeks. I'm developing in 6.2 full time and would like to give it another month just to see if any show stoppers pop up.

Ross

[Jeff Crumb]

Version 6.1 has been very stable for us. We have a number of customers running that now in production.

We are now developing in 6.2 and also find it very stable. I would definately suggest moving to Version 6.2 from 5.5.


Jeff

[Lewis Mccabe]

Thanks Ross and Jeff. Are any of your installs running SQL Server?

[Jeff Crumb]

Thanks Ross and Jeff. Are any of your installs running SQL Server?

Yes we are running SQL Server.

[Lewis Mccabe]

Any changes/improvements with SQL Server and PROIV from 5.5 to 6.2?

With SQL Server in 5.5, SQL timeout had to be used for record locking. Have they corrected this? From what I understand, SQL Server record locking is now supposed to work the same way PRO-ISAM does. Does the lock logic get honored in a SQL Server environment? Any issues with locks not getting released? Does PROIV recognize a locked record quickly? etc. Could you elaborate on this subject?
Thanks.

[Ross Bevin]

Hi Lew,

Yes, we run 6.1, and now 6.2 in development, with MS SQL Server. When we were on 5.5 we were running SQL Server 2000 and now on 6.1/2 we are running SQL Server 2005.

Yes, you still need to use SQL Timeout.

Yes, lock logic is executed. However, if you get locked on the first primary table of a screen function the function waits based on the SQLTIMEOUT period; lock logic is then executed and then the read is aborted and control returns to the last read field.

Yes, sometimes we have a lock that won't get released. It doesn't happen often but it can when you are in a lock situation and trying to kill a session with ProIV Session Manager fails. It really hasn't been much of an issue for us though.

No, ProIV with SQL Server does not work the same as ProIV with Pro-ISAM.

My biggest gripe with ProIV/SQL locking is the situation when an update or report has been locked by a screen function. E.g. a user is in the Customer Maintenance screen and goes for lunch while another is running Invoicing. You can't kill the locked session with ProIV Service Manager; it ignores the kill request. You either need to get the screen function user to exit or you kill the screen function.

This is how we handle our SQL locking. When a user logs on we have a temporary table that records their company & branch; it is keyed on terminal ID; the table is called NA_OPRL. We also do a SQL call to get and store their SQL SPID and record this as well in NA_OPRL. We also have a SQL job that runs every minute which updates another table (NA_LOCKS) with lock information; it is empty if there are no locks. We had to do this because with SQL 2005 my SQL View to read the system table use to frequently lock itself. Finally, I have a ProIV function running every minute in the background that checks NA_LOCKS for any entries. If any exist I can then use the lock and locking SPID's to determine the user who is locked and the user doing the locking. The function then e-mails the users involved informing them of the situation they are in. The function also e-mails the administrator. It repeats the e-mailing process every minute until the lock clears and will e-mail again once the lock clears.

These are our pro4v6.ini settings for SQL Server 2005 on 6.1/2.

LOCKED_ROWS_RETURNED=Y
LOCK_TIMEOUT=Y
SQLSERVE_SELECT_FOR_UPDATE=TRUE
SQLSERVE_TABLE_LOCKING=Y
SQLTIMEOUT=30
SQL_ADD_UPDLOCK=Y
CURSORS=AUTO
SQL_DISABLE_TIMESTAMP_CHECK=Y

While I'm on the subject of MS SQL Server there is one important difference between 2000 and 2005. When you run a report or update with SQL Server 2000 the query runs in parallel on dual/quad processor servers. In 2005 the query will only run in series; 2005 thinks this is the most efficient method. So you can have the all this souped up hardware but 2005 will not take advantage of it. This may be fine in a large environment where you don't want a single user hogging the server. It doesn't work well though in a smaller environment where the server is not being taxed to it's full potential. Before we migrated our live environment from 5.5/SQL Server 2000 to 6.1/SQL Server 2005 I did some benchmark testing on the same hardware. Reports and updates ran 30% TO 50% slower on 2005. Fortunately we upgraded the hardware for the migration so effectively the speed didn't change.

[Lewis Mccabe]

Hi Ross,

Thanks for the in depth reply.


Regarding lock logic: You reference a difference between how the primary file is handled vs secondary files. Could you elaborate? Are there any instances where the lock logic is executed quickly instead of having to wait for SQL_TIMEOUT?

Customer file maintenance locking batch update: We finally got fed up with this scenario and began using PROIV timeout. All users now know if they leave their PROIV session open too long, they will loose their work. Our cust maint screen has a lot of child windows so potentially a user could loose a lot of work but they have learned. We don't hear anything about it any more. Once in a while, locks are not released on timed out sessions. We turn off the timeout for batch updates. On some critical screens we turn off the timeout and restore it upon menu return.

We don't have any customers on SQL Server 2005 yet. I always code in anticipation of increased hardware speed - I add new features even if they are slow, knowing the situation will resolve itself. 30-50 percent performance loss is going to be a killer for us. We assumed the SQL 2005 engine had been optimized. I did a Google search and found your posts on sqlteam.com and see you have researched this issue quite a bit. I think I may simply stay with SQL Server 2000 for now (if this can be done in PROIV 6.2)

Lew