Hi,

Well, it's not actually about modifying dbsrvr.exe. What I started to
do is write a different server. Basically I need a very specialized
server for a suite of apps. The thing is the server itself would do
some work in order to release the clients of code they actually don't
need (say there's a lot of computation to do at night, when nobody uses
tour apps).

At his point I have a TForm with an engine component (practically it's
a derived class) and I can have a client connect and access for example
a table and, at the same time I can display in the server a grid with
the same table (this is basically a local session on server itself). I
did this just to see how this application (the server) would work.

The question is: even though now it seems the simple stuff works, at
this point is very primitive and I need to know if I am on the right
track on this, if it's ok to continue, and if it would continue to be
safe if the server will become multithreaded and access tables in
various databases from multiple threads, also with clients attached
(obviously without clients will work just fine).

TIA,
Lucian

"Lucian Radulescu" <lucianATez-delphiDOTcom> wrote in message
news:xn0fm8p6toqsgt000@news.elevatesoft.com...
> Hi,
>
> Well, it's not actually about modifying dbsrvr.exe. What I started to
> do is write a different server.

Why reinvent the wheel? dbserver has all the setup required to run as a
process, tested and ready to go. Can't you simply expand it and write your
procedures using the existing framework?

Robert

Basically I need a very specialized
> server for a suite of apps. The thing is the server itself would do
> some work in order to release the clients of code they actually don't
> need (say there's a lot of computation to do at night, when nobody uses
> tour apps).
>
> At his point I have a TForm with an engine component (practically it's
> a derived class) and I can have a client connect and access for example
> a table and, at the same time I can display in the server a grid with
> the same table (this is basically a local session on server itself). I
> did this just to see how this application (the server) would work.
>
> The question is: even though now it seems the simple stuff works, at
> this point is very primitive and I need to know if I am on the right
> track on this, if it's ok to continue, and if it would continue to be
> safe if the server will become multithreaded and access tables in
> various databases from multiple threads, also with clients attached
> (obviously without clients will work just fine).
>
> TIA,
> Lucian
>

> Can't you simply expand it and write your procedures
> using the existing framework?

I don't need the existing "framework" and I'll have first to shrink it.
And if I do that, I'll have the form and the engine. Which is what I
have now.

> Why reinvent the wheel?

Basically this wheel is round. I need a squared one


--
Lucian

Lucian Radulescu wrote:

> I don't need the existing "framework" and I'll have first to shrink
> it.  And if I do that, I'll have the form and the engine. Which is
> what I have now.


(?)...  I wrote a lot of C/S app's with a lot of procedures and
triggers...

But I never saw a "framework"...
So, what kind of "framework" is this you are talking about?.. did I
miss something?

... regards,

ralf

> But I never saw a "framework"...
> So, what kind of "framework" is this you are talking about?.. did I
> miss something?

You did. I did not mention "framework" first. In this context however,
I meant by framework the existing UI.

Lucian

Lucian,

<< The question is: even though now it seems the simple stuff works, at this
point is very primitive and I need to know if I am on the right track on
this, if it's ok to continue, and if it would continue to be safe if the
server will become multithreaded and access tables in various databases from
multiple threads, also with clients attached
(obviously without clients will work just fine). >>

Yes, yes, yes, and yes.

The only thing that you cannot do from a server is start up a remote session
that will attempt to access another server.  Apart from that, it's just
alike any other application that you write using DBISAM.

--
Tim Young
Elevate Software
www.elevatesoft.com

Robert,

<< Why reinvent the wheel? dbserver has all the setup required to run as a
process, tested and ready to go. Can't you simply expand it and write your
procedures using the existing framework? >>

We actually have a lot of customers that do what Lucian is proposing, and it
really is very simple to do, especially if you don't want/like the existing
interface and don't want to run it as a service, which are the two main
things that the existing dbsrvr.dpr provides.

--
Tim Young
Elevate Software
www.elevatesoft.com

> Yes, yes, yes, and yes.

Allrightie


> The only thing that you cannot do from a server is start up a remote
> session that will attempt to access another server.

Not that I need that now, just curious ... why? Is it hard to
fix/change that? It seems like a lot of fun being able to connect a
server to another server

Thanks,
Lucian

Lucian,

<< Not that I need that now, just curious ... why? Is it hard to fix/change
that? It seems like a lot of fun being able to connect a server to another
server >>

It's an architectural issue with DBISAM.  ElevateDB can do it, but we don't
allow it at this point.

--
Tim Young
Elevate Software
www.elevatesoft.com

On 2/10/08 12:32 PM, in article
6D628E3D-E4AA-412D-9349-D0521DB5CBEC@news.elevatesoft.com, "Robert"
<ngsemail2005withoutthis@yahoo.com.ar> wrote:

>
> "Lucian Radulescu" <lucianATez-delphiDOTcom> wrote in message
> news:xn0fm8p6toqsgt000@news.elevatesoft.com...
>> Hi,
>>
>> Well, it's not actually about modifying dbsrvr.exe. What I started to
>> do is write a different server.
>
> Why reinvent the wheel? dbserver has all the setup required to run as a
> process, tested and ready to go. Can't you simply expand it and write your
> procedures using the existing framework?

That is what I did.

I copied Tim's dbsvr code and added what I needed.

Here are some screenshots
http://www.activebiometrics.com/products/activeserver/index.html