I am creating an application that needs to store data for multiple portals. Each portal is a different customer.

I know I can use the portalid or portalname in the SQL SELECt but these things can change. (Company names change, portals get moved to other servers, etc.)

I want to create a new token that is at the portal level where I can store a code. I will use this code as a token in my SQL selects so I get the data for the correct portal... even if the company name changes or the portal gets moved.

For example (XModPro):

SELECT * FROM mydata WHERE companycode = '[[Portal:companycode]]'


Is there any way to create a new token at this level? Otherwise, ideas on how to do this are welcome. (Not user profiles because the same user may log into multiple portals.)

Thanx

PortalID should be invariant within a single DotNetNuke installation.

I know about PortalID. BUT, sometimes, I have to move a client from one host to another. So, if I have to pull their data out of one hosting site and move it to another I cannot be sure their PortalID will be the same.

Yes, I also know I could translate it, but still, for disaster recovery and such, I really would like to keep things separate. I am also thinking ahead. There will probably be other thinks that I want to designate at the portal level.

We have User Profiles, too bad there are no Portal Profiles. I started looking at Inject Anything but it looked like it did not inject tokens at portal level. So, I am still thinking my best bet is to find a way to create tokens at a portal level. Is there an .ascx file I can create or modify that would accomplish this?

Have you thought about creating a custom list?  You can add named entries to the list, and you can store text strings.  Since token replacement is now a provider, I'm sure that you could create a custom token replacement provider that adds additional tokens.  You could pull that data from your custom list.  Doing it that way means that you're not fiddling with the core code.

Unfortunately, I haven't seen anything about the token replacement provider ... but that's something else to think about.