PLEASE REPORT: on testing of Server once again!

[Keith DeLong]

Ruslan,

>>> Glad to see you on testing, Keith.
>> 
>> It's great to see the server alphas becoming available.
> 
> Oh, actually on our side works practically all V4RB functionality!
> I was so in hope give you ready for use server.

We'll get there....

> And such trap... :-(

More data points:

(1) I ran the project using different names in different locations, all
generating the same error 9.

(2) I ran the project in RB 5.1 with the same results, error 9 in IDE, and
works in a compiled app. What's interesting (besides that it works with the
new compiler :-) in this is that in RB5, an IDE run is compiled outside the
IDE and launched in a separate memory space.
 
(3) The error seems to be strictly with the client:
After successfully creating database1 in compiled app, if I go back to IDE
and try 'Open' command, I get the same error 9.

After successfully creating database1 in compiled app, if I go back to IDE
and try 'New' command, I get the same error 9

In fact, when I run the project in the IDE without the server even running
and select New or Open, I get the error 9.

(4) To follow-up on Robert's note, .errnumber is 9 so you are catching it in
V4RB. The errorstring is empty.

So it appears to be a V4RB client generated error happening before an event
ever gets out to the server. The vserver.log file for the server does not
show it, but opening the OSX console app does show it:

  16:32:30.489016 (2684358124) ----> VSRV_Server::SetOutputMode_i()

/***************************************************************************
**********/
Tue Apr 29 2003 16:32:30.489789 Valentina Server (2.0 alpha, Protocol 1.0,
Kernel 1.9.8b4)

 16:32:30.553933 (2684358124) Server started at 5432 port
 16:32:30.554357 (2684358124) Thread pool activated (5)
 16:32:30.555566 (2684358124) Thread pool activated (15)
 16:32:30.558059 (9276640) ----> VSRV_Server::svc()
 16:32:30.558461 (9276640) Accepting thread started
error  9

error  9

error  9

 16:32:52.288879 (2684358124) ----> VSRV_Server::~VSRV_Server()
 16:32:52.289395 (2684358124) ----> VSRV_Server::StartUp()
 16:32:52.289576 (2684358124) ----> VSRV_Server::ShutDown_i()
 16:32:52.292061 (693840) Thread deactivated
 16:32:52.292603 (694784) Thread deactivated
 16:32:52.292955 (695600) Thread deactivated
 16:32:52.293281 (9174384) Thread deactivated
 16:32:52.293695 (9180384) Thread deactivated
 16:32:52.294025 (9186400) Thread deactivated
 16:32:52.294363 (9192416) Thread deactivated
 16:32:52.294675 (9198432) Thread deactivated
 16:32:52.295117 (9204448) Thread deactivated
 16:32:52.295491 (9210464) Thread deactivated
 16:32:52.295846 (9216480) Thread deactivated
 16:32:52.296167 (9222496) Thread deactivated
 16:32:52.296488 (9228512) Thread deactivated
 16:32:52.296800 (9234528) Thread deactivated
 16:32:52.297113 (9240544) Thread deactivated
 16:32:52.297427 (9246560) Thread deactivated
 16:32:52.297741 (9252576) Thread deactivated
 16:32:52.298207 (9258592) Thread deactivated
 16:32:52.298542 (9264608) Thread deactivated
 16:32:52.298866 (9270624) Thread deactivated
 16:32:52.573343 (9276640) ----> VSRV_Server::close()
 16:32:52.574413 (9276640) Server terminated


>> Any idea how soon we'll see record locking so we can start testing
>> multi-user performance? I lost a key employee this month so I'm working lots
>> of extra hours -- but I hope to have time soon for some serious testing :-)
> 
> Record locks is an issue of one day of work.
> Not a big deal...

This is great news. Looking forward to the next release :-)

Keith