Using ASP and Access 2002.

The simplied SQL statement is "UPDATE dbtable SET status=" & xstat

and xstat is a boolean value (almost always=True) The SQL works just fine on at least a dozen different servers in the US.

I have a client in Brazil . When they run the asp file... their server prepares the SQL to look like...

UPDATE dbtable SET status =Verdadeiro (which means True in Brazilian.)

This simple SQL statement throws an error...

Microsoft JET Database Engine erro '80040e10'

Nenhum valor foi fornecido para um ou mais parâmetros necessários.
No value given for one or more necessary parameters

The field names and types are correct, and as I said above, this code works fine on many servers in the US

*************

Any ideas about what I must do to solve this issue... as the boolean values seem to have Brazilian words attached to them that my US prepared database doesn't understand.

Tim

You may have an answer already, but I'll throw some ideas at you anyway.

This site displays error nessages for the number you have below...
http://www.webthang.co.uk/tuts/tuts_.../gk_errors.asp
This is the error it reports: [This happens when one of the column names specified in your recordset SQL statement does not exist in the database table you are trying to query. ]

Also what is the datatype of the field? Did you double check it? And true and false can also be 0 and 1 (or it may be -1 and 0 in VB). Write the var to the page (comment out the SQL call first) so you can see it. Make sure the datatypes match.

Hope this helps.

Thanks for the thoughts... but this same exact code runs fine on nearly a dozen US based servers. It's inside of a common subroutine I use all the time. I've updated my post to reflect this fact.

This has something to do with the language pack or locale... I don't know what...

Additional Facts:

If I hardcode :
SQLx="UPDATE dbtable SET status=True"
and then execute it, it works fine.

If I hardcode:
xstat=True
SQLx="UPDATE dbtable SET status=" & xstat
response.write SQLx

The code fails with the error I mentioned... and the SQLx string looks like: UPDATE dbtable SET status =Verdadeiro

Go figure. Any other ideas?

Tim

Verdadeiro ou falso? Hehe, este é brazilian meu amigo. Certifique-se por favor verificar o locale da entrada e começá-lo fazer exame da nota da língua. brazil[portuguese]

verdadeiro = true
falso = false

Thanks for completely clearing up the problem for me... NOT!

But I did chuckle!

Tim

Haha, at least you have a sense of humor, man some people get mad if you don't spell it out for them... i mean, it's not like i'm getting paid here.... so glad you have a sense of humor

It's brazilian as you know. They use verdadeiro as true and falso as false, but in vbscript there's a GetLocale funtion you use to get the input locale. and vice verca you can you SetLocale("some language code") to change the code.

locale chart here
http://msdn.microsoft.com/library/de.../vsmsclcid.asp

You can case the language input and make it =true instead of using xstat strait from the user. Is that what you're looking for, i'm not sure if that grabs the default language or not *shrug*, i think it's just the current input typing.

It sounds like the client isn't actually initializing that, and if they aren't, you'll have to get their location orientation another wya, but still you can just do checks before you query the DB and get the input to the DB squared away with english assuming all your production servers are english based as it sounds. Hope this helps

Note, if you were mean i wouldn't have said any of this

Thanks...

Actually, I've been experimenting with locale Id's, and think I have the issue solved.... and the only solution that worked was to functionlize all my database updates and inserts... and include a Session.lcid change to US before the update, and back to whatever it was afterwards.

I don't know that it's a very classy solution... but for right now, it works... as I take some time to learn more.

My MAJOR issue is that whatever I do I need to keep the code fairly portable, as I use it on numberous servers.

Tim

I just read the original post and didn't see you put portuguel as teh language, sorry, i was just hastly writing which language it was thinking that's what you wanted so sorry about that.

This is actually part of my job is dealing with this. The way we have it set up is the database is standard English same way you're doing it. It's probably the best way to do it just to keep the data consistent. We have a second table with all the users and their language preference. Then what we return can be based off what their language preference since obviously some people might be in america but be using french primarily.

Maybe I'm completely wrong, it'd be nice to hear how other people have it set up but mine's the same as yours. But I didn't set it up and that's just the way it is so i work with it. Let me know if you have anything else to ask about, it helps me to here that other people are doing it this way too at least cause it seems sloppy but for consistency sake it seems the best which is pretty key for a DB... even though ours never is... ugh.

regaurds,
Kevin