Domain name problem - weblogic.developer.interest.wls6.1(Archived)

Hi,
In our web application running on wls6.1SP4 we are having this problem that when we are using the fully qualified domain name (ie blah.com.au) Our EJB is not returning the correct results from the database. It will do the first search correctly but all searches after this will always return the results from the first search.
However, if we just use the sort version of the domain name (ie blah) it works correctly and always returns the correct results.
Has anyone had this problem before? Any help would be very much appreciated.
Cheers,
Keith. 

not that i know of any, but can you check if nslookup works fine when using just the hostname and not the domain name.

Related

Odd parameter form issue

I have an odd problem in an oracle 10.1.2 report.
It has a parameter form with a drop down list of teams and a start and end date.
I put in a default date of sysdate in the before parameter form trigger. however when we run this on our test environment (and I assume our live one) even if you overwrite the default dates, the report always runs just for today.
This runs fine from the reports builder, and running against my test OC4J server on my development PC.
The only difference is that for real it runs using a secure parameter form - using a java bean to encrypt the logon credentials.
Has anyone seen this issue before? It's got me absolutely stumped.
regards,
Carl 
Hi Karl,
1. Make sure you are connecting to the same database in both the cases and check the sysdate value from sqlplus
2 Disable the java bean and try running it.
3 print the parameter values being passed and the dates being taken.
4 Check for any exception part in the code and remove the lines not related with date.
Good Luck !!
Rajesh 
Thanks,
I'm definitely connecting to the same database - and this is happening against our development and live database.
Unfortunately I can't disable the java bean in the real application - it's 3rd party and I don't have the source. I could try knocking my own form as a test harness though.
The dates are already printed in the header of the form, it's definitely only using the defaults if one is set.
For now I have removed the defaults and am just printing some extra help text on the parameter form. 
Ok.. Let me know whether it works fine.

AdminSettings v4.5ws

I have a gadget thats on both my production and development portals.Funny thing is, when I edit the admin prefs for the gadget in developoment and save them (AddAdminSettings) it works fine. BUT, on production, this line of code falls over saying "Operation not Allowed". Weirdly, other gadgets on both systems do NOThave this problem so I figure its not different GDK version issues. Therefore logic makes me think is there some sort of limit on the adminsettings for a given gadget or some other limit that is causing the AddAdminSettings methoid to fail? Can someone please shed light?Thanks, Wayne
Hi Wayne,
Can you please post the troublesome bit of code and the error you are getting?
Thanks,
ross
Is it possible that you have the gateway configured differently in the two systems?
Hi Guys, the thing is its not complicate code and other admin gadgets on the same portal are working fine on admin prefs (so not gateway issue esle all would be erring), and the codes used in other gadgets and it works so bit pointless pasting in here, but here goes anyway:===============================================================Response.buffer=true: dim oSettings: set oSettings=Server.CreateObject("GSServices.Settings")set dSystemSettings=oSettings.GetGatewaySpecificConfigdim dAdminSettings: set dAdminSettings=oSettings.GetAdminSettingsdAdminSettings(Request.Form("CommunityID") & "MainText") = Request.Form("MainText")dAdminSettings(Request.Form("CommunityID") & "SubHeading") = Request.Form("SubHeading")dAdminSettings(Request.Form("CommunityID") & "Image1") = Request.Form("Image1")dAdminSettings(Request.Form("CommunityID") & "Image2") = Request.Form("Image2")dAdminSettings(Request.Form("CommunityID") & "Layout") = Request.Form("Layout")oSettings.AddAdminSettings(dAdminSettings) ==> ERRRORING WHEN IT HITS HERE!Response.Redirect("AdminPrefs.asp")===============================================================
Any lateral ideas would be really appreciated!
Wayne
By the way, here's the error:
Error Type:Response object, ASP 0104 (0x80070057)Operation not Allowed...setAdminprefs.asp, line 20
Hi Wayne,
There is a size limit to admin prefs and the limit is usually mandated by the size of the field in your database you use for storing the admin prefs (i.e. the plumtree db has a table called something like PTGlobalPrefs...PTMYPAGESPREFS is the 4.5 table name for user and portlet prefs) . Anyways the size of the row value if using MS SQL as your db I think gets capped off at 255 characters. I once had a framework portlet that was storing a really large value as an admin pref and it would not save the value once it was ovwer 255 characters due to the constraint put forth by my the database. The save to the db failed and the preference change was not saved. Just an idea to check...hope it helps.
-john
Under the covers, AddAdminSettings() tries to call Response.AddHeader() to send the values of the new settings back to the portal. For some reason, the Response object doesn't like this call:
Response object, ASP 0104 (0x80070057)Operation not Allowed
One possible cause is that part of the HTTP body has been written out, so it is no longer possible to add headers. It doesn't look like this should happen from the snippet you pasted above, but if there's some code above it, or it's included in another file, that could be the cause.

3.0 EA2 Find Database Object doesn't work correctly sometimes

Example: i pick my connection and in name i will have something like "ssont%pkg%" with/without the check box for % checked. doesn't matter, you hit the lookup button and you get stuff that in no way matches this criteria. i can get something like fnd tables, or just abc123. It seems to just pull random stuff. Sometimes it will work fine and sometimes it works like this. There are 3 of us with this version installed and it does it to all of us however our 2.1 versions don't have this issue and still work fine. We downloaded the 3.0 EA2 with the JDK. 
more information, if the type is set to all types you get this stuff, but if you go in and select the types (ie tables, packages) there are no problems. 
Reproduced: 10425327 
are they going to be fixing this? i couldn't find that id you gave me how may i get to it? 
Bugs marked "internal" (filed internally) are not visible for the outside world... changed the customer field to "forum".

friendly urls not resolving

We recently noticed that some "friendly" urls in our portal are no longer working - give "this page does not exist or user does not have access to it". Has anyone else seen this behavior and/or found a workaround?
Webcenter interaction version is 10.3.01.
We're pretty sure it is NOT a permissions issue - happens with the administrator login too, and the communities resolve fine if we use other url formats.
The error happens if we try to resolve the page using community name only (e.g. http://eportal/portal/server.pt/community/research). If we include the community object id, its fine (e.g. http://eportal/portal/server.pt/community/research/214 works). We'd really like to be able to publish links without the object id in there though!
It happens only on some communities, and at no particular time that we can determine - one day the link will work, and the next it doesn't. We have checked the database repeatedly, and these communities do exist, with the name we're using in the friendly url, and without duplicates - though there are other communities with similar names (e.g. "research" and "research and EBP council"). I've even gone so far as to run a trace on my db while trying to access these, and as far as I can tell the portal isn't even trying to resolve the community name from the db. It looks like maybe it's relying on search results....but when I search manually I can't find any problem their either. 
We are on 10.3.0.1 and have always had to include the object ID at the end.
One option is to just create web server shortcuts. They are a lot more reliable!
user10103864 wrote:
We recently noticed that some "friendly" urls in our portal are no longer working - give "this page does not exist or user does not have access to it". Has anyone else seen this behavior and/or found a workaround?
Webcenter interaction version is 10.3.01.
We're pretty sure it is NOT a permissions issue - happens with the administrator login too, and the communities resolve fine if we use other url formats.
The error happens if we try to resolve the page using community name only (e.g. http://eportal/portal/server.pt/community/research). If we include the community object id, its fine (e.g. http://eportal/portal/server.pt/community/research/214 works). We'd really like to be able to publish links without the object id in there though!
It happens only on some communities, and at no particular time that we can determine - one day the link will work, and the next it doesn't. We have checked the database repeatedly, and these communities do exist, with the name we're using in the friendly url, and without duplicates - though there are other communities with similar names (e.g. "research" and "research and EBP council"). I've even gone so far as to run a trace on my db while trying to access these, and as far as I can tell the portal isn't even trying to resolve the community name from the db. It looks like maybe it's relying on search results....but when I search manually I can't find any problem their either. 
i would agree that i have seen oddities around this but i have seen it work without the object id at the end so given that you have a community created named 'test' with id 205 you can use:
- http://eportal/portal/server.pt/community/test
- http://eportal/portal/server.pt/community/test/205
even http://eportal/portal/server.pt/community/blahblah/205
but not http://eportal/portal/server.pt/community/tests
since you say that it works sometimes and other times it does not i makes me want to think that it is related to a specific server if you are load balanced. is your system load balanced? I don't believe that the lookup is related to search as you should be able to turn the search server off and still have it resolve. it is most likely built into the filter on the portal server so either one of your load balanced portal servers is misbehaving or your db connection is flaky. you can turn on PT spy and only enable the DB piece of the tree and create a new community to see what db queries are run. you can also see if a quick query is run when trying to resolve an address(with or without a an ID in the url) or if this is being cached at some point.
-robert

BI Query not giving same results as Database Query

I have a query in BI that populates the default value on a prompt. Recently it stopped populating the correct value. When we run that same query on the database (we are using Toad), we get the correct answer. Any ideas why the query works fine on the database, but not in BI? Thanks! Dennis
What have you analyzed so far? Checked the logs? The logical SQL? The physical SQL? The cache? Because things don't just magically change.a) there was a change andb) you're most likely not looking at "that same query"
As long as you executed the same exact query using the same exact account against the same exact database you must remember you also have the local settings playing a role in how a query is executed. If with all the above mentioned elements being the same your Toad gives you a different result than OBIEE (and you are 200% sure you aren't just hitting the cache because you forgot to manage it and enabled it hoping to fix some performance things) it means your query is a bit badly formed and you maybe need to make it more strict to avoid local settings (like languages etc.) impacts. But I would definitely look twice at the logs first to be sure your query is still execute correctly on the right database as in general you have that when you have cache in between ... edit: writing more than Christian in the same time but going in the same direction 
I want to provide a quick follow-up on this. We noticed we had the same issue in Dev.  The BI server variable containing the query we are using to populate the default value was not working correctly. After we redeployed the RPD file, the query started working again.  While this is good news, it sounds like a spin-off of the "reboot" solution.  Something happened to make this stop working. I'm just not sure what that is at the moment. We're going to try the same thing in Production and keep our fingers crossed that this will work. 
Another variable refresh issue?

Categories

Resources