Hi ,
Over a single internet connection i tried downloading a zip file from
Aolserver and from Nginx. Aolserver was giving me download speed in my
particular case 10-15 KB/s , whereas same file downloaded from Nginx with
more than 800 KB/s .
Both Nginx and Aoslerver (4.5.1) are hosted on the
I don't know the fast Tcl extension to parse HTTP headers.
May be wrapping this project
https://github.com/joyent/http-parser
will be useful to build pure Tcl web servers.
--
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
--
AOLserver - http://www.aolserver.com/
To Remove yourself from
On Thu, Oct 27, 2011 at 01:42, Dossy Shiobara do...@panoptic.com wrote:
discontinuing
their LISTSERV service as of November 1st, 2011.
What were the reasons cited? Just curious.
FC
--
The purpose of computing is insight, not numbers.
Richard Hamming -
Hi,
There has been little discussion or response to this matter, and the few
responses have all been in favor of moving the lists to SourceForge.
Today is the 26th, so I'd like to do the list move sometime tonight or
tomorrow. Consider this the last call for comments or objections.
Thanks
On Wed, Oct 19, 2011 at 09:25, Dossy Shiobara do...@panoptic.com wrote:
Does anyone have a strong preference as to where to relocate the lists?
Any good reasons why they shouldn't move to SourceForge?
I have been the admin on a virtualbox-related mailing list on
SourceForge with great results.
Op Wed, 26 Oct 2011, schreef Dossy Shiobara:
Hi,
There has been little discussion or response to this matter, and the few
responses have all been in favor of moving the lists to SourceForge.
Today is the 26th, so I'd like to do the list move sometime tonight or
tomorrow. Consider this the
Op Tue, 25 Oct 2011, schreef Jeff Rogers:
I'll take a swing at getting this integrated sometime soon (available time
waxes and wanes, as I'm sure it does for all of us). This patch is a bigger
piece of functionality that the others I put in; I think 4.6 is the right
target for this.
Yup,
SF sounds ok to me
On Oct 26, 2011, at 6:43 AM, Dossy Shiobara do...@panoptic.com wrote:
Hi,
There has been little discussion or response to this matter, and the few
responses have all been in favor of moving the lists to SourceForge.
Today is the 26th, so I'd like to do the list move
Dossy: Thanks for handling this!
-JIm
On Oct 26, 2011, at 9:43 AM, Dossy Shiobara wrote:
Hi,
There has been little discussion or response to this matter, and the few
responses have all been in favor of moving the lists to SourceForge.
Today is the 26th, so I'd like to do the list move
Dear AOLserver Community,
On October 17th, AOL has informed us that they will be discontinuing
their LISTSERV service as of November 1st, 2011. For over 10 years now,
the AOLserver community's email lists have been hosted through this
offering.
Since the AOLserver open source project is
I think from the tcl perspective the interp management is interesting.
Interps are initialized with a startup script (created through
introspection) and reused by multiple requests without reinitializing
(cleaned up after each request, again using introspection).
-J
Matthew M. Burke wrote:
Agreed -- this has always been one of the must unique and/or goofy aspects of
AOLserver and Tcl. I gave the keynote at the 7th (yes, 7th!) tcl/tk conference
years ago:
http://www.aolserver.com/docs/intro/tcl2k/
You could mention how this work has continued on and off over the years.
Hi,
Cool! Nice updates :)
On the version # question a few days back, I agree this is 4.x update. For a
5.x release, in addition to what you listed below, I'd add:
-- integrate SSL support directly (comm driver, api's)
-- integrate the comm drivers
-- figure out some better build environment
Op Tue, 25 Oct 2011, schreef Jim Davidson:
Hi,
Cool! Nice updates :)
On the version # question a few days back, I agree this is 4.x update. For a
5.x release, in addition to what you listed below, I'd add:
-- integrate SSL support directly (comm driver, api's)
-- integrate the comm
Good catch -- trying to get IP6 working makes sense as well.
-Jim
On Oct 25, 2011, at 3:54 PM, Daniël Mantione wrote:
Op Tue, 25 Oct 2011, schreef Jim Davidson:
Hi,
Cool! Nice updates :)
On the version # question a few days back, I agree this is 4.x update. For
a 5.x
Daniël Mantione wrote:
Maybe I could point again at the ipv6 patch I wrote in 2008. Back there
was even not even a response on this list, but maybe today, now the
world has run out of ipv4 addresses, the interrest in serving ipv6 is a
bit higher.
Patch still available for download here:
Later this week, the 18th Tcl/Tk conference will be held and one of the
sessions is a panel discussing the different ways to use Tcl to do web
development.
I have been asked to discuss AOLserver and as I finish up my notes, I
thought I should check with the folks on this list to see if
Hey all, me again.
For those of you who don't monitor the commits list I wanted to share a
few changes I've recently made as well as a few I'm still thinking about.
- implemented native decoding of strings in ns_returnfile. This allows
filenames that are not utf-8 to be passed, similar to
Everyone,
It appears that AOL is going to be shutting own its LISTSERV, which
includes several AOLserver mailing lists.
Since there's still activity on this mailing list, I think it would be
worth moving to a new list. SourceForge offers GNU Mailman lists as
part of its project hosting
Sourceforge seems a reasonable choice to me.
-J
Dossy Shiobara wrote:
Everyone,
It appears that AOL is going to be shutting own its LISTSERV, which
includes several AOLserver mailing lists.
Since there's still activity on this mailing list, I think it would be
worth moving to a new list.
Hi Jeff
congrats on all the great work. That all sounds super. A new AOLserver release
would be amazing, but maybe seeing as 4.0 was first released 8 years ago, we
could consider that it's about time for a move to 5.0? Not wanting to get too
Firefox-y about it, but I think it would be good for
Hey Jeff,
I'm about to start using aolserver for the first time in many, many years, so
your post is very encouraging, and the changes look good. Your exposed the
gzip flag to tcl scripts (ns_conn gzip) item reminded me that I believe I had
promised some code a while back on that...and I
On Wed, Oct 19, 2011 at 05:09:48PM +0100, Fenton, Brian wrote:
A new AOLserver release would be amazing, but maybe seeing as 4.0
was first released 8 years ago, we could consider that it's about
time for a move to 5.0?
I guess he should just bump the version number up to 9.0 then, that'd
look
On Oct 19, 2011, at 6:51 PM, Andrew Piskorski wrote:
On Wed, Oct 19, 2011 at 05:09:48PM +0100, Fenton, Brian wrote:
A new AOLserver release would be amazing, but maybe seeing as 4.0
was first released 8 years ago, we could consider that it's about
time for a move to 5.0?
I guess he
Fenton, Brian wrote:
Hi Jeff
congrats on all the great work. That all sounds super. A new
AOLserver release would be amazing, but maybe seeing as 4.0 was first
released 8 years ago, we could consider that it's about time for a
move to 5.0? Not wanting to get too Firefox-y about it, but I think
Brett Schwarz wrote:
I'll grab the latest and greatest from SF and start messing around with
your changes. Is SF the main repo for aolserver? What about the modules
(specifically nspostgres)?
Yep, SF is still the place for aolserver and nspostgres (which looks
like it has been updated to
Thorpe Mayes wrote:
Hi,
I am trying to install the solid database drivers and cannot do it.
I am running aolserver 4.5.0.
I added the nssolid_3.0 driver. I then added solid-fix.tar, which updated the
Makefile file and added the nssolid.h file to the nssolid directory.
Where is
Hi Jeff,
Thanks for the note.
The nssolid3_0.tar file generates a Makefile and a nssolid.c file.
When I run the solid-fix.tar file, the Makefile is updated (the Makefile that
nssold3_0.tar generates is missing some definitions) and it creates a file
named nssolid.h. The solid-fix.tar file is
Hi,
I am trying to install the solid database drivers and cannot do it.
I am running aolserver 4.5.0.
I added the nssolid_3.0 driver. I then added solid-fix.tar, which updated the
Makefile file and added the nssolid.h file to the nssolid directory.
When I run make I get this result:
make
Klaus Hofeditz ]project-open[ wrote:
I gave it a try since some of our users do upload files using tools
such as WINSCP. Since these files would also need to be accessible
through the ]project-open[ file manager, we need to come up
with a slightly more complex solution to detect files with
Hi Guan,
What is the value of [encoding system] on a
regular page or in the context where you call ns_returnfile?
"[encoding system]" returns utf-8
just before running "ns_returnfile 200 $type $file"
If I set "encoding system iso8859-1" before
On Sunday, September 25, 2011 at 06:42 , Klaus Hofeditz ]project-open[ wrote:
Hi Guan,
- Show quoted message -
[encoding system] returns utf-8 just before running ns_returnfile 200
$type $file
If I set encoding system iso8859-1 before ns_returnfile 200 $type $file
Hi Guan,
How confident are you that the underlying file name is UTF-8?
[file readable $file] returns '1' - this might be evidence
enough for a UTF-8 file name
ns_returnfile 200 $type [encoding convertto utf-8 $file]
negative :(
tx everybody for the very useful input!
Using ns_returnfp is (for several reasons) not an option for us.
Recompiling tcl using
--with-encoding utf-8
did not resolve the problem. This time I used AOLserver 4.5.1 /
tcl8.5.10.
What is the value of [encoding system] on a regular page or in the context
where you call ns_returnfile?
On Sep 25, 2011, at 0:00, AOLSERVER automatic digest system
lists...@listserv.aol.com wrote:
tx everybody for the very useful input!
Using ns_returnfp is (for several reasons) not
Hi all
at ]project-open[ we currently use AOLserver 4.5.0 with OpenACS
5.6.0 on CentOS release 5.3 (Final)
We suddenly encountered the problem that ns_returnfile can't find a
file which filname contains special chars such as 'umlaute'
(, , etc.)
---
convmv tells me
Just a guess here, but by default, TCL is compiled with Latin-1 encoding. This
causes some issues when you are trying to do certain things in utf-8, even if
you set all possible TCL config variables to use the UTF-8 charset. You could
attempt to recompile TCL with
--with-encoding utf-8
Howdy,
Looking at the code, ns_returnfile passes the filename through to the core
Ns_ConnReturnFile without any of the care that core Tcl does handling
filenames. You may be able to replace ns_returnfile with ns_returnfp, passing
a file handle returned from Tcl's open command which should be
Another thing you could do is to set tcl's default encoding to utf-8, so
that the filenames passed to Ns_ConnReturnFile are the same encoding as
what the core tcl commands do.
Set the default encoding with
encoding system utf-8
in some tcl file. It's possible this could have some side
The Debian package for aolserver doesn't install nsproxy properly
http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=bugs%40davidosborne.co.uk
Alternative amd64 packages are here:
http://debian.qcode.co.uk/dists/squeeze/main/binary-amd64/
-- Bernhard van Woerden
On 30 January 2011 19:37,
Without seeing your config file and the file.tcl file mentioned previously it
is impossible to determine why.
But the place to start looking is the config file or
/aolserver/modules/tcl/file.tcl
The error is not in YOUR .tcl file. The file
/aolserver/modules/tcl/file.tcl
has functions
Hi,
When I run this code to show a web page (or any code that shows a web page):
ns_log Notice TEST
set data html
head
Hu
Check: /aolserver/modules/tcl/file.tcl
It would seem like your procedures are registered but that your errorPage
variable is never set.
A quick fix may be to change the line:
if { $errorPage == } {
to
if {![info exists errorPage] || ($errorPage == ) } {
Date:
I don't really see why there's an error either. But if you fix the problem
that is masking the error reporting, you'll have a much better chance of
finding out.
Rusty
On Aug 22, 2011, at 8:50 PM, Thorpe Mayes wrote:
Hi Peter,
Thanks for the response.
I did not make myself clear. My
Many thanks for the patch. it looks good. it applied with
some minor related cleanups.
-gustaf neumann
On 17.08.11 19:06, Jin Choi wrote:
Hello. I've tracked down and fixed a crashing bug in AOLserver on x64. I
believe it is correct.
AOLserver was crashing with
Fatal:
Hello. I've tracked down and fixed a crashing bug in AOLserver on x64. I
believe it is correct.
AOLserver was crashing with
Fatal: munmap(0x, 0) failed: Invalid argument
I tracked down the only call to munmap in NsUnMap in nsd/fastpath.c. It takes
the return value of NsMap and
Dear all,
i did some more digging/googling in this issue and i share
the opinion that - at least for the time being -
Tcl_Finalize() could be omitted on windows versions without
too much harm. Some background:
The Tcl manpage says:
*Tcl_Finalize* is similar to*Tcl_Exit* except
Dear Gustav,
Thank you.
Alls well that ends well
Im not sure all the changes I suggested are still in the codebase
especially the ones in RED
It is not up to Aolserver/nsd include system to define SOCKET as int on
Windows.
Thank you again,
Maurizio
On 07.08.11 17:37, Maurizio Martignano wrote:
Dear Gustav,
Thank you.
All's well that ends well...
I'm not sure all the changes I suggested are still in the
codebase... especially the ones in RED
The reason, i have not committed theses two suggested
changes to the code
Dear Gustav,
You ARE ABSOLUTELY RIGHT!
And I AM DEFINETELY A VICTIM OF ALZHEIMER.
APOLOGIES
Ciao,
Maurizio
From: AOLserver Discussion [mailto:AOLSERVER@LISTSERV.AOL.COM] On Behalf Of
Gustaf Neumann
Sent: 07 August 2011 19:02
To:
Maurizio,
Tcl_Finalize() is supposed to work, and if it does now work
something is still broken in the windows version. Omitting
Tcl_Finalize() is removeing the symptom, not the cause. It
is not unlikely that something else will have the same
problem due to this cause.
When Tcl_Finalize()
Dear Gustav,
I understand perfectly than omitting the function is
removing the symptom and not the cause,
but process/service wise having Tcl_Finalize in that particular place (where
the process/service is about to end) or not having it doesn't make any
difference. The Operating
YES. I do agree that executing or not executing the exit handlers may make a
difference..
Just to help me in my troubleshooting can you tell me if and where these
handlers are registered.
I am digging into Tcl_Finalize.. J
Thank you,
Maurizio
From: AOLserver Discussion
It is me again.
Well I noticed that the change I suggested about Tcl_Finalize did not make
it into CVS HEAD.
If it doesn't go there, I am afraid I will have to anyhow introduce it
myself in my distribution.
I need to have a working system. With that call still in, the service can't
(CANNOT) be
Dear Dossy,
Your proposal of your wrapper sounds good to me.
Why do not we insert that in the codebase? Till we understand better the
issue?
Next week I am going to redo some testing also in Win32 and I will let you
know..
Thank you very much,
Maurizio
From:
Hello all
I did some tests on Windows 32.
Tcl_Finalize prevents the proper stopping of the service also on Windows 32.
So the proper mod was and still is:
// Conditional compilation clause added by M. Martignano on the 05/08/2011
#ifndef _WIN32
Tcl_Finalize();
#endif
I vaguely remember never figuring this out either and deciding to ifdef it out.
In practice it doesn't do much -- I've never come across a on-exit handler
that really needed fire. Curious if anyone has.
Jim
Sent from a phone
On Aug 6, 2011, at 3:29 PM, Maurizio Martignano
Dear Maurizio and all...
i have updated cvs on sourceforge with most of your patches.
A few points are questionable (see below).
For me, it is still unclear, why 4.5.1 worked for you, but
not the head version not. As far i can see,
all socket usages were int the same way in 4.5.1, the
Dear Gustav,
Thank you so much for you feedback.
I just distributed a new mail with an explanation for the patches..
Sorry if it arrives too late..
I will answers your questions here below.
Once again, sorry for the bad timing.
Ciao,
Maurizio
From: Gustaf Neumann
Dear Maurizio,
i guess, everything is fine with you with the head version
on sourceforge.
For me, it is still unclear, why 4.5.1 worked for you, but
not the head version not. As far i can see,
all socket usages were int the same way in 4.5.1, the
variable triggers in nsd.h was defined like
On Fri, Aug 05, 2011 at 02:22:44PM +0200, Gustaf Neumann wrote:
For me, it is still unclear, why 4.5.1 worked for you, but
not the head version not. As far i can see,
all socket usages were int the same way in 4.5.1, the
variable triggers in nsd.h was defined like this at least
since
Dear Gustav,
I understand your concerns about Tcl_Finalize. but it is
called just when the process/service is about to end.
Once it ends the OS takes charges and releases the process/service resources
(memory included).
You can make an easy test.. Have Aolserver / nsd running on
Yup -- seems like it's worth keeping the Win32/Win64 port going. It does muck
up the code a bit with ifdef's and there are a few weirdnesses with Windows to
work around but I suppose enough effort has been done in the past (if not
recently) that it wouldn't be too tough to maintain.
-Jim
If that is ok,
I am willing to take the burden to look at / look after these
weirdnesses...
Ciao,
Maurizio
-Original Message-
From: AOLserver Discussion [mailto:AOLSERVER@LISTSERV.AOL.COM] On Behalf Of
Jim Davidson
Sent: 05 August 2011 18:05
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re:
Dear all,
Id like to provide you with very few examples to explain
what I was talking about:
These problems manifested themselves in the Win64 version
driver.c
void
NsWaitDriversShutdown(Ns_Time *toPtr)
{
Driver *drvPtr = firstDrvPtr;
int status = NS_OK;
On Aug 4, 2011, at 12:24 AM, Maurizio Martignano wrote:
inttrigger[2]; /* Wakeup trigger pipe. */ ß Why is
this an int when it was a SOCKET (any justification)
A Unix pipe is just a pair of file descriptors, and a file descriptor in Unix
is just an integer.
It's probably safer to define this as SOCKET, but windows.h says SOCKET is:
typedef u_int SOCKET;
And:
typedef unsigned intu_int;
Since Windows is LLP64 and most Unix-like systems are LP64, I don't
understand how AOLserver's defining trigger[2] as (int) is the problem
--
Dear Don,
I went back to my archives
This is the situation:
1. the code in CVS had always
int trigger[2];
2. I took the version 4.5.1 from the tar ball dated 2009-02-02 and I did the
change
SOCKET int trigger[2]; to make it work
3. then I recently took the Aolserver code from CVS Head
It is not a matter of understanding
It is a matter of testing
On Windows 64 int trigger[2] doesnt work whereas SOCKET trigger[2] does
work.
On top of that in several other places SOCKET has been used, so if for no
other reason, I suggest one of the code maintainers takes a proper walk on
On Win64, can you tell me what sizeof(SOCKET) and sizeof(int) are? Try
this simple program:
#include windows.h
#include winsock2.h
int main(int argc, char[] *argv)
{
printf(sizeof(SOCKET) = %d, sizeof(int) = %d\n,
sizeof(SOCKET), sizeof(int));
return 0;
}
I just learned
Dossy,
It is irrelevant...
Absolutely irrelevant..
With
int trigger[2]
static void
TriggerDriver(Driver *drvPtr)
{
if (send(drvPtr-trigger[1], , 1, 0) != 1) {
The send doesn't work and always returns error
With
SOCKET trigger[2];
It DOES Work...
Back to your question:
The
On Aug 4, 2011, at 7:20 AM, Maurizio Martignano wrote:
5. I have to disagree with your statement
A Unix pipe is just a pair of file descriptors, and a file descriptor in
Unix is just an integer.
Feel free to disagree with the official Linux documentation then:
Dear Don,
If you follow the last discussions even Dossy agrees that a SOCKET
is not an int on Windows 64
All of this depends on the week type system of C, were types with different
names, supposed to be used for different needs are considered equivalent is
their size is the same. If we
On Aug 4, 2011, at 9:55 AM, Maurizio Martignano wrote:
All of this depends on the week type system of C, were types with different
names, supposed to be used for different needs are considered equivalent is
their size is the same. If we had used Ada none of this would have had
happened:
Dossy Shiobara wrote:
It's probably safer to define this as SOCKET, but windows.h says
SOCKET is:
The source comment is misleading, because trigger is set up as a socket
pair, not as a pipe. Not sure why it's this way, but there it is. And
ns_sockpair is already prototyped as
Don
In Aolserver source code
95% of more of the times sockets are declared as SOCKET; the other times as
int.
This is an inconsistency and is a fact.
If you wanted to develop only for Unix why did you use SOCKET in some
occasions and int in some others?
The source code is inconsistent and it
Hi
It's a socket so it can be monitored by select and poll. It should be SOCKET, I
think it was in the past.
On windows lib-c file handles returned by _open aren't the same as sockets.
You can see this in the libc source Microsoft provides. They can't be
monitored with select. The
Maurizio,
I think we're all in agreement at this point. Could you put together a
patch?
-J
Maurizio Martignano wrote:
Don
In Aolserver source code
95% of more of the times sockets are declared as SOCKET; the other times as
int.
This is an inconsistency and is a fact.
If you wanted to
We are reasoning too much...
1. Compiling the code on Windows 64 made clear there's some inconsistency in
the code...
2. This inconsistence is on how sockets are declared: 95% and more of the times
as SOCKET and the rest of the times as int
3. On UNIX and WIN32 no problem cause SOCKET and int
Dear Rusty,
I started very politely, gently...
Stressing I was seeing that the code base was kind of separating, moving
away from Windows support... (I did see how SOCKETwere used).
Then I provided the examples
Then I stressed the int trigger[2];
Then I made it clear and I am
We are in violent agreement...
It was never my intention to raise the discussion to this level.
I just observed the code.
I may have used tones a bit too strong or too stressing...
I never used bad words...
I am going to provide a patch that will remove the inconsistencies I tried
to explain...
It
Hi all,
I'm implementing a minor enhancement to the adp parser to make null end
tags (aka empty elements or minimized tags) work. Or more simply, if
you have a registered adp tag where the end tag matches the opening tag,
then rather than
mytag name=value/mytag
you can simply write
mytag
Hi,
I'm looking at the code now -- definitely needs to be SOCKET in nsd.h. The
reason can be seen in ns_sockpair in fd/sock.c where the code for a socket pair
is done. It's just a wrapper around Unix socketpair() but has a bunch of extra
code to do the loopback-connect thing on Windows. The
Sounds good to me.
-Jim
On Aug 4, 2011, at 4:21 PM, Jeff Rogers wrote:
Hi all,
I'm implementing a minor enhancement to the adp parser to make null end tags
(aka empty elements or minimized tags) work. Or more simply, if you have a
registered adp tag where the end tag matches the
I am doing the scan and I am preparing the patch.
I will have also to do the testing as some of my customers do require the
Windows 64 version.
And I may offer to do this testing also in the future, non on a continuous
basis, but every now and then.
Ciao and thanks,
Maurizio
Dear all,
I'm the maintainer of the Windows Port of OpenACS.
Recently (22/07/2011) I got the CVS HEAD version of Aolserver and compiled
it with Microsoft Visual Studio 10 for Windows 32 bit and Windows 64 bit.
I did this because I wanted to take profit of the mods
Maurizio Martignano wrote:
Well… ehm... the version in the tar ball compiles and runs well under
Windows…
Not so for the version under CVS HEAD: many of the changes introduced
have been implemented with a careful eye only for *nix, and not for Windows.
By looking at the code I have the
I speak only for myself ...
I personally have thoughtfully cared for the Windows support in
AOLserver -- once upon a time, I had built the Windows binaries that
some folks were using. Through discussions I had with Jim Davidson, the
new build mechanism for AOLserver 4.5.x was meant to make
Hello all,
Some few clarifications, I am afraid I wasn't clear.
The compilation in itself was rather simple and went almost ok.
The issue was in the behavior in the testing
Some of the code, eg, function calls to the networking parts and so on, are
working in the tar ball
Hi,
As Dossy mentioned, we spent some time trying to support the win32 port. That
included a goofy Tcl-based config thing (which also helped to verify a workable
Tcl installation) and a dose of ifdef's and compatibility code. In general,
the AOLserver code base is decidedly Unix -- any Win32
Hi Jim,
Once again I'll take ]project-open[ as example.
Please look in here:
http://sourceforge.net/projects/project-open/files/project-open/V3.5/
How big is the Windows Installer (which installs on both Windows 64 and
Windows 32 systems)?
How big is the VMware Image?
Well in some
Also, try first solving the problem of reading from the database. So if you
have some data in a table that you know is correctly stored, try a sql query
from AOLserver, and see if you can pinpoint where it gets converted.
Once you have that sorted, writing to the database should be solvable.
Also take a look at the CharExpansion parameter. I had some issues with that a
few years ago (and the documentation seems to be back to front just to make it
even more confusing!). :-)
http://www.mail-archive.com/aolserver@listserv.aol.com/msg09664.html
I don't think it's tcl at this point. I can see that aolserver/tcl can bring
in the unicode characters and return them to the client 'as is'.
And you can see what encoding system tcl is using via this command as well:
[encoding system]
which shows that tcl is using UTF-8, which is what is
It might be that the Oracle driver doesn't handle those column types. Is there
anything in the AOLserver log? Maybe turn on debug to get more info.
Brian
From: AOLserver Discussion [AOLSERVER@LISTSERV.AOL.COM] On Behalf Of Brad Chick
I just grabbed the latest oracle driver from cvs and you are right: there is
no explicit support for either NCHAR or NVARCHAR2 - which oracle requires to
store unicode characters.
So, I will try to update the driver and report back.
Thanks
--
AOLserver - http://www.aolserver.com/
To Remove
Well, I reached an impasse. I grabbed the latest source from CVS, added
support for the 2 datatypes (NCHAR, NVARCHAR2), and recompiled. Then, I
turned on debugging for the driver.
The logs look great. The driver constructs the queries appropriately:
e.g.
Make sure that any vars set in your shell environment that relate to this are
also set in your nsd wrapper script. I wish I knew for sure if that is enough
for them to be effective, but I don't. I vaguely recall that the C API the
driver uses is called Pro-C on the Oracle side - you might
Brian many thanks, i commited your change to the CVS on
sourceforge.
-gustaf neumann
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
lists...@listserv.aol.com with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Dear Gustaf (and all)
thanks Gustaf for the fixes - reading your code, it's interesting to see how
AOLserver works internally. And it's all so elegant, meaning even I can follow
it! I can confirm your fix has resolved the 413 problem. I attempted to take it
a step further and add a 413
1 - 100 of 10259 matches
Mail list logo
