Focal Point Banner


As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.

Join the TIBCO Community
TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.

  • From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
  • Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
  • Request access to the private WebFOCUS User Group (login required) to network with fellow members.

Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.



Read-Only Read-Only Topic
Go
Search
Notify
Tools
Maintain Question
 Login/Join
 
<kat92182>
posted
Hi,

This is for anyone who is currently using a Maintain application in a production environment. I have a case open because I cannot get my Maintain application to run when I have the datasource set up as an SU database. It is currently with the programmers because they cannot find a solution to my problem. I am wondering if anyone out there is using a Maintain w/ an SU database? I am really confused as to how I could be the first person to want to allow simaltaneous users to use my application. From what I found in my testing, without SU, only one person can add or update a record at a time. Thanks!
 
Report This Post
Virtuoso
posted Hide Post
Have a customer who has been using Maintain with SU for 7 years. I coded over 100 maintains for them, all SU, never had a development issue and had only one issue with db corruption before a 4.3 patch applied, none since. Works like a charm. This is Windows 2000 server now but still on 4.3.1 plus patch (nightmare) and on 4th machine now (smaller than my laptop), have clocked over 80 concurrent Maintain users and runs 24/7.

Have also set up/coded for other maintain SU environments and trained on maintain with SU and have never encountered a real issue.

My development environment is now 7.6 plus SU for maintain, also have used Update Assist with SU (about 40 procs) and those went into User Testing okay as well.

There has to be something basic wrong here IMHO.


Alan.
WF 7.705/8.007
 
Posts: 1451 | Location: Portugal | Registered: February 07, 2007Report This Post
Virtuoso
posted Hide Post
Same story here.
Customer with SU maintain, runs worldwide, so 24/7an dno problems whatsoever.

Would you please be so kind to update your profile, so we can se what webfocus version you're using?

Also, what have you got in your edasprof to instruct the system to go SU for your databases?
Where are the masters located, and where are the databases? Did you store the path in the suprof profile (if it is not the standard path)?


GamP

- Using AS 8.2.01 on Windows 10 - IE11.
in Focus since 1988
 
Posts: 1961 | Location: Netherlands | Registered: September 25, 2007Report This Post
<kat92182>
posted
-*USE
-*ATFOCALL ON FOCSU01
-*END

We found that commenting out those lines permits the application to run on our server. Both the master and database are on baseapp.
 
Report This Post
Virtuoso
posted Hide Post
On the basics front, for a windows application, the following should be set up:

In SUPROF.PRF (c:\ibi\srvNN\wfs\etc) point to data directory and MFD directory, something like:
APP DISABLE
SET EDAPATH=C:\someplace\META;C:\someplace\FDS; 


In EDASPROF.PRF (c:\ibi\srvNN\wfs\etc) something like:
SET COMMIT=ON
APP PATH myApp meta fds
-*
USE
file1.FOC ON FOCSU01
file2.FOC ON FOCSU01
END


In ODIN.CFG (c:\ibi\srvNN\wfs\etc) something like:
.
.
;FOCUS Database Server
NODE = FOCSU
BEGIN
  PROTOCOL = TCP
  CLASS = SUSERVER
  PORT = 8122
END

;FOCUS Database Client
NODE = FOCSU01
BEGIN
  PROTOCOL = TCP
  CLASS = SUCLIENT
  HOST = localhost
  PORT = 8122
END
.
.


Check that FDS in Special Services in webconsole is running.

Use only FOCUS db (SUFFIX=FOC), SU will not work on any other file including XFOCUS.

As far as I am aware, that should be it.

What symptoms are you getting?

(Edited to add required SET COMMIT=ON into EDASPROF.PRF, though can be in group or user profile instead. Thanks for pointing that out Mark.)

This message has been edited. Last edited by: Alan B,


Alan.
WF 7.705/8.007
 
Posts: 1451 | Location: Portugal | Registered: February 07, 2007Report This Post
Master
posted Hide Post
We believe that the SU problem that you are having is due to very large fields. I believe programming is close to getting a fix.

Alan - do you still need to set fds_access = y in the EDASERV.CFG? I thought we needed that step.

Mark
 
Posts: 663 | Location: New York | Registered: May 08, 2003Report This Post
<kat92182>
posted
I just finished implementing the steps from Alan (we were missing some of it), and ran the application, and I don't seem to be getting the error anymore!!! Thanks Alan for the info! I am going to do more testing, but it seems to be fine now.
 
Report This Post
Virtuoso
posted Hide Post
That's an interesting point Mark. I have fds_access=y in the 4.3.1 scenario, but not in 7.6.n. Cannot remember 7.1.

I suppose I should ask you whether it is necessary or not, but do seem to manage without it.

Interesting is that in the (stalled) dev/uat system we are using A3000 fields in a few places, but normally only one in a focus file, messages, comments etc. but have no issues with those. Would be interested in results/more info just in case.


Alan.
WF 7.705/8.007
 
Posts: 1451 | Location: Portugal | Registered: February 07, 2007Report This Post
  Powered by Social Strata  

Read-Only Read-Only Topic


Copyright © 1996-2020 Information Builders