The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic

Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.

If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.

Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.

Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Request.Remote_Addr does not return client IP

  • Filter
  • Time
  • Show
Clear All
new posts

  • Request.Remote_Addr does not return client IP

    I have a grid that grabs specific info and sets up the session variables immediately after the user logs in. One of the things I need is the users IP address and I am using Request.Remote_Addr to get it. When running the page locally, it is retrieving my computers IP address correctly - But - when the page is viewed from my production server through a real domain, Request.Remote_Addr is retrieving the visitors ISP address.

    Is there another way or method of getting the visitors IP address ? Getting their ISP's address is not very useful

    simple code I'm using is..... myfield = Request.Remote_Addr

    Any suggestions or input is much appreciated, thank,s Dave

  • #2
    Re: Request.Remote_Addr does not return client IP


    One of us is confused. Your visitors PC is behind a cable modem for example. The visitors PC IP address is something like but the wan address of the cable modem is for example and that address is registered to the ISP. That is the unique address for the visitor during the current session. There are millions of PCs around the world with an IP address of but only one WAN address of I do not understand the need to know what the lan address is of the visitors PC. There is nothing you can do with it if you could get it which by the way I do not know of a way to get it. The wan address is unique to the visitor at the time of the session. Be forewarned that the wan address provided by the visitors ISP can change.

    To find your wan address just browse to

    Hope that helps.
    Jeff Ryder


    • #3
      Re: Request.Remote_Addr does not return client IP


      I didn't state my questions very well and understand the 192.168..x.xx stuff and how/why it isn't accessible.
      Here's a better description.... there's 50 computers in an office sharing one internet connection through the companies cable modem. Using your example, I expected to see, 002, 003, and so on, with the last digits representing each device. But I am seeing the same value, say, for all users in that location. This client uses dynamic IP's on all their workstations and I get that too. My clients IT guy wants a report showing the login ID, IP, Date and Time each time the site is logged into from their office. I can't say how or why he's going to use it, I just thougt this would be a slam dunk ...


      • #4
        Re: Request.Remote_Addr does not return client IP

        In most cases, your client's 50 computers will share the one public ip address.
        The IT guy in question should know that you will only be able to get the wan
        address for each login, in addition to the loginID, Date, and time.

        Maybe he wants to verify that they're logging in from the office computer instead
        of a mobile device or from home.


        • #5
          Re: Request.Remote_Addr does not return client IP


          Since most ISP's provide a single "public" IP the clients local router uses DHCP to assign individual IP addresses to each connected computer. The router uses a single IP for all internet traffic. Even with a t1 for example you may get 5 usable public IP's (as we do in our office) but the DHCP server protects individual computers by hiding them behind NAT (network address translation). It is impractical to get anything other than the public ip if users access the WAS by a fully qualified domain name (FQDN).

          One variation is if the WAS is on the local network and users access it by a local ip address (ie or which is the same subnet as the clients. In this case your request for the client ip address will pull the local ip and be device specific. If the DHCP serves assigns ip addresses dynamically (as is commonly the case) then the same client may pull a different local IP today than it does tomorrow depending on the lease time and whether the client computer is restarted.

          To ensure that the actual user (id) and computer are retrieved for your logs you may want to consider using client certificates which are tied to the hardware.

          I find that using strong authentication requirements and ip filtering on the known ips for your authorized users can meet most logging needs.