Data Portal Issue with 3.5.0.0

system · June 5, 2007, 4:06pm

I just updated the 3.5.0.0. Everything works fine, Ayanova, WBI, and generator. But I seem to be having problems with Data Portal. Before upgrading, I had no problems. Here is the message I recieve on the remote computer when using the data portal function:

AyaNova was unable to start

Depending on how early in startup the problem occurred,
a detailed log of the problem with suggestions may have
been saved to the file AyaLog.txt
located at: file:\C:\AyaNova 3

Error details:
Unhandled Exception:
Exception has been thrown by the target of an invocation.
System.Reflection.TargetInvocationException
Inner exception: Unable to complete network request to host “70.233.225.9:6969”.

Stack Trace:

Server stack trace:
at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at CSLA.Server.DataPortal.CallMethod(Object obj, String method, Object[] params)
at CSLA.Server.DataPortal.Fetch(Object Criteria, DataPortalContext context)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at CSLA.Server.DataPortal.Fetch(Object Criteria, DataPortalContext context)
at CSLA.DataPortal.Fetch(Object Criteria)
at CSLA.Security.BusinessIdentity.LoadIdentity(String UserName, String Password)
at CSLA.Security.BusinessPrincipal…ctor(String Username, String Password)
at CSLA.Security.BusinessPrincipal.Login(String Username, String Password)
at GZTW.AyaNova.BLL.AyaBizUtils.0()
at GZTW.AyaNova.BLL.AyaBizUtils.Initialize()
at AyaNova.Form1.0()

Does anyone know why I am getting this???

AyaNovaSupport · June 5, 2007, 4:30pm

Hi

I would suggest checking and doing the following:

-you have upgraded the Data Portal to 3.5.0.0 - correct? - compare file versions and dates to those that are in the AyaNova 3.5.0.0 program folder
-have you restarted IIS completely?
-have you rebooted the IIS server computer itself?
-go back through the steps of setting up a Data Portal where on the server you enter in the URL http://localhost:XXXX/AyaNovaDP/DataPortal.rem?wsdl

does that work on the server itself (where xxxx is the port number of IIS (doublecheck what the port should be for IIS)
-double-check what the external ip address and port number is to make sure someone or something has not changed it
-also enter the IP address instead of local host along with the confirmed port number - i.e.
-compare the Web.config connection string to that of an internal networked connection AyaNova.exe.config that is connecting to the database successfully - does it have the exact same connection to the same port number, same ip address , same username , same password ?

Do post your results back what you find

Joyce

AyaNovaSupport · June 6, 2007, 6:49pm

Hi again

Do post back the details.

If you determined the issue, do post what it was for the benefit of all.

Thank you

Joyce

system · June 11, 2007, 9:20am

I am still having the same problem.

*I made sure I used the 3.5.0.0 download off the website by redownloading the Data Portal file and reinstalling it.

*I restarted everything

*Using http://localhost:XXXX/AyaNovaDP/DataPortal.rem?wsdl & http://XXX.XXX.XXX.XXX:XXXX/AyaNovaDP/DataPortal.rem?wsdl, work on the server

*All the ports, IPs, and usernames seem to be correct.

Any more ideas? Or could I email you my files and get some more detailed help?

Thanks,

Tory

AyaNovaSupport · June 11, 2007, 9:37am

Hi Tory

You can always email directly to support@ayanova.com at any time- support is usually provided the fastest via the forum, as well as being of benefit to other AyaNova users.

I was hoping that you would confirm the items listed in my previous reply as that may show you where the issue is. If you want to email me directly the information instead of posting, that is fine. But do provide the specific details.

I’ve listed them again below as well as identified even more so what I suggest checking:

-go back through the steps of setting up a Data Portal where on the server you enter in the URL http://localhost:XXXX/AyaNovaDP/DataPortal.rem?wsdl

does that work on the server itself (where xxxx is the port number of IIS (doublecheck what the port should be for IIS)
-double-check what the external ip address and port number is to make sure someone or something has not changed it
-also enter the IP address instead of local host along with the confirmed port number - i.e. compare the Web.config connection string to that of an internal networked connection AyaNova.exe.config that is connecting to the database successfully
does it have the exact same connection to the same port number, same ip address , same username , same password ?

With the information that http://localhost:XXXX/AyaNovaDP/DataPortal.rem?wsdl & http://XXX.XXX.XXX.XXX:XXXX/AyaNovaDP/DataPortal.rem?wsdl work on the server - when you entered in http://XXX.XXX.XXX.XXX:XXXX/AyaNovaDP/DataPortal.rem?wsdlwas xxx.xxx.xxx.xxx:xxxx a local ip address? if so, what was it?, or did you enter the same external ip address identified in your first topic 70.233.225.9:6969 ?

Does entering the URL using 70.233.225.9:6969 in web browserwhen on the server work?

Is this 70.233.225.9 the IP address of your router? - double-check in case something has changed

Is 6969 the port you have opened on that router that is pointing to the internal ip address of the server? - double-check in case something has changed

Is the internal IP address of the server the exact same internal ip address identified in the router configuration? - double-check in case something has changed

Is 6969 the port identified for AyaNovaDP and the default web site in IIS on this server? - double-check in case something has changed

Is port 6969 been set up in this server’s firewall to be allowed through? - double-check in case something has changed.

Joyce

system · June 11, 2007, 10:18am

Joyce,

Port 6969 is still cofigured correctly in IIS and on the router. 70.233.225.9 is the IP of the server running AyaNova. None of this has changed and it worked before I upgraded to 3.5.0.0. I used http://localhost:6969/AyaNovaDP/DataPortal.rem?wsdl & http://70.233.225.9:6969/AyaNovaDP/DataPortal.rem?wsdl, both returned:

<?xml version=“1.0” encoding=“UTF-8” ?>

As far as I can tell everything appears to be correct. I will copy all the text files below for you to double check. I appreceriate you taking a look at this for me.

Here is my ayanova.exe.local configuration:

<?xml version=“1.0” encoding=“utf-8”?>
<CONFIGURATION>

</APPSETTINGS>
</CONFIGURATION>

Here is my ayanova.exe.dataportal configuration:

<?xml version=“1.0” encoding=“utf-8”?>
<CONFIGURATION>

Here is my web.config in the AyaNovaDP default web site:

<?xml version=“1.0” encoding=“utf-8” ?>
<CONFIGURATION>
<SERVICE>
<WELLKNOWN <br mode=“SingleCall”>objectUri=“DataPortal.rem”
type=“CSLA.Server.DataPortal, CSLA.Server.DataPortal” />
<!–
<wellknown mode=“SingleCall”
objectUri=“ServicedDataPortal.rem”
type=“CSLA.Server.ServicedDataPortal.DataPortal, CSLA.Server.ServicedDataPortal” />
–>

</SERVICE><!-- DYNAMIC DEBUG COMPILATION
Set compilation debug=“true” to enable ASPX debugging. Otherwise, setting this value to
false will improve runtime performance of this application.
Set compilation debug=“true” to insert debugging symbols (.pdb information)
into the compiled page. Because this creates a larger file that executes
more slowly, you should set this value to true only when debugging and to
false at all other times. For more information, refer to the documentation about
debugging ASP.NET files.
–><COMPILATION
defaultLanguage=“c#”
debug=“false”
/>

<!-- CUSTOM ERROR MESSAGES
Set customErrors mode=“On” or “RemoteOnly” to enable custom error messages, “Off” to disable.
Add <error> tags for each of the errors you want to handle.

      "On" Always display custom (friendly) messages.
      "Off" Always display detailed ASP.NET error information.
      "RemoteOnly" Display custom (friendly) messages only to users not running 
       on the local Web server. This setting is recommended for security purposes, so 
       that you do not display application detail information to remote clients.
--&gt;&lt;CUSTOMERRORS

mode=“Off”
/>

<!-- AUTHENTICATION
This section sets the authentication policies of the application. Possible modes are “Windows”,
“Forms”, “Passport” and “None”

      "None" No authentication is performed. 
      "Windows" IIS performs authentication (Basic, Digest, or Integrated Windows) according to 
       its settings for the application. Anonymous access must be disabled in IIS. 
      "Forms" You provide a custom form (Web page) for u

AyaNovaSupport · June 11, 2007, 10:21am

Please always attach files in a WinZip file to your topic posting.

None of the information came across.

Joyce

AyaNovaSupport · June 11, 2007, 10:26am

When you attach the files to your reply, also provide the results of having done the following:

-On the server itself where IIS is and AyaNovaDP is and the database is, rename the existing AyaNova.exe.config to something like AyaNova.exe.configNETWORK
-Now rename the AyaNova.exe.configDATAPORTAL to AyaNova.exe.config
-Edit this new AyaNova.exe.config so that it is using the localhost:6969 connection
-Now on this server run the AyaNova program - does it bring up the AyaNova login screen?
-If it does, shut down the AyaNova login and edit the AyaNova.exe.config so that it now uses the router ip 70.233.225.9:6969
-Now run the AyaNova program again - does it load the AyaNova login screen?

What you are doing above is troubleshooting down to where the issue is directly occurring. Do let me know.

Joyce

system · June 11, 2007, 10:43am

Joyce-

Sorry for that. Here are the files. I tried what you said, replacing the network config file with the data portal file. I got the same error as get with a remote computer when I used localhost:6969 and 70.233.225.9:6969.

-Tory

AyaNovaSupport · June 11, 2007, 10:53am

Hi Tory

I am assuming that you had edited all of the attached files replacing the actual password with****** - correct?

-Put back the original AyaNova.exe.config file so that you are connecting again with the network Firebird connection - don’t forget that you need to edit the password and make sure it was not left at *********
-Run the AyaNova program - are you able to log into AyaNova from the server?
-Run AyaNova program from a local area networked computer connecting via the network Firebird connection - are you able to access the database as well? - again, make sure you have the correct password, connection etc in there

Joyce

AyaNovaSupport · June 11, 2007, 10:55am

Hold on a second - is 70.233.225.9 the server’s actual internal IP address? Isn’t that your router’s IP address?

On the server, open a command prompt and type in ipconfig

What is the actual ip address of the server where the database resides, where IIS is running and where you have AyaNovaDP installed to?

Joyce

AyaNovaSupport · June 11, 2007, 11:11am

You’ve got DataSource=70.233.225.9:6969 in the web.config, but are using DataSource=70.233.225.9; in the AyaNova.exe.config

The web.config should be using the exact same connection string as your local network Ayanova.exe.config connection string.

If 70.233.225.9 is your server’s internal IP address, than you need to edit your web.config so that it is using only DataSource=70.233.225.9; - it should NOT have the port number in it.

If 70.233.225.9 is NOT your server’s internal IP address, than both your internal network AyaNova.exe.config and the web.config should be using the actual internal ip address of the server (or the server’s computer name).

Let me know once you have edited these. If you are still having a problem, zip up the AyaNova.exe.config for a local networked computer that defintely does work connecting to AyaNova just now, and zip up the edited web.config that is using the same connection string as the AyaNova.exe.config and identify what any errors are etc and exactly from what program running what connection you get the error.

Joyce

system · June 11, 2007, 11:14am

Yes I edited the password. I am able to login in on the local server. If I try to use the data portal on a computer on the network it returns the original error still. I am not sure what you mean by “via the network Firebird connection?”

-Tory

AyaNovaSupport · June 11, 2007, 11:20am

In the AyaNova.exe.config you are using the connection string for connecting to a networked Firebird AyaNova database. That tells me you are using a network Firebird connection.

In the AyaNova.exe.config you have DataSouce identified as the ip address 70.233.225.9

But in the Web.config you have the DataSouce identified as the ip address AND also a port number 70.233.225.9:6969which is not correct for the Data Protal connection in web.config

As above, what is the actual internal IP address of your server where the Ayanova database is, where IIS is running and where this AyaNovaDP is installed onto - I asked above that you run ipconfig on the server

Joyce

system · June 11, 2007, 11:27am

Thank you, turns out the port number did not need to be in the web.config file. I thought I saw that in the manual some where. Everything should be working fine now!

-Tory