Atozed Forums

Full Version: Unexpected behavior. What am I missing ?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi Guys,

I'm trying out the new SA httpsys option, and it works really nice. However, I do have some strange and unexpected behavior I hope some of you could explain or help point me in the right direction:

First:
I have a small test application with a datamodule with an ADOConnection and an ADOTable. Connection points to the MSSQL server and is set to Windows authentication, and testconnection work fine. However, I do not set the Connected property nor the Active property on the table. In unit1 I have a listbox and in Formshow, a call to a procedure "ShowMenu" listing the content of adotable.

The unexpected behavior is that the application do show the content of the table in the listbox, despite me not calling the adoconnection.open method, nor setting the connected property. Even if I tick LoginPrompt (without a onlogin event), it still connects silently. Only when I change authentication to SQL user, provide a name but no password, it will not connect. Instead I get an error "Colinitiate has not been called!".

The above test is when run with visible GUI. Why do it connect even though I have not set the Connected property nor called the Open method ?

Second:
When setting the connection properties as supposed, recompiling it as a service, installing it on the target machine, and trying to call it in the browser, I do get the unit1 form up on the screen, but with no data (not even those simple iwlabel1.caption := 'test'Wink, and the procedure to open the table and show the contents in the listbox, fails with an access violation error.

So the same program works fine as GUI, but fails as a Service. I suppose it is an authentication problem, where the service runs with another user than the one logged on to windows, but not even when entering the SQL user and password in the ADOconnection, do it work. It is the same whether the service is installed locally on the SQL server, or on the development pc.

I hope someone else have had the same problem and have found a solution.
Looks like the user which is running the service doesn't have the necessary permissions.

After installing your service, go to services management console ("services.msc") find your application there and double click to configure the properties.

Se example below (it is a google service but the same applies to all services).

Select a local administrator user and set the password correctly. Restart the service and try again.

[attachment=124]
I have uploaded a new demo which uses ADO DB. It is SA (Indy) but it makes no difference if you use SA Http.sys.

Also, the Coinitialization error message is fixed setting ServerController's ComInitialization property (you can set it to ciNormal).

The demo is here:

https://github.com/Atozed/IntraWeb/tree/...WADODBDemo

Is is very simple but it shows some important concepts used for all IW DB applications, regardless of DB and engine used to connect to it.

Most important concepts are:

- Where to put the connection
- Where to put the DataSet objects (queries, tables, etc.)
- How to use these objects from the visual containers (the form where you have visual controls)

In this example:

- Connection is put into the user session object, meaning that each user has an exclusive DB connection. This works well if you have a limited number of simultaneous users
- DataSet objects (Queries) are put into DataModules which are owned by forms. I *personally* follow a very strict design which is: each form has its own DataModule (I also have some shared DataModules which can also be used by several forms). This design has proven to be efficient and much easier to maintain in the long run.
Regarding the problem of the SA httpsys, when running as a service, giving access violation when opening the ADOConnection, I have been told that especially ADO has problems when running as a service. Would any of you be able to confirm that ?

Or maybe put in other words: Has any one managed to create a SA Httpsys service, opening and reading data from a ADO table ?
There are no problems associated with ADO and services. Whoever told you that is not sticking to the facts.

I've used ADO in dozens of services working flawlessly 24x7.

Any service needs to be properly configured. The account which runs the service very likely has different privileges and might not have access to all needed resources. If you have an AV opening ADOConnection you need to check:
- How is your ServerController.ComInitialization setting (try Multithread and see if it works)
- If the account running the service has sufficient privileges to connect to the database.
Hi Alexandre,

Sorry for not getting back to you before now, I've been busy moving my development forward.

I have switched back to .DLL and IIS 10, as it is working and I can continue my development. I've used too much time trying to get the SA HTTPSYS version past the Access violation. I've decided to wait with the service version to later, and to get my main application developed. Once it is working as a DLL, I can change it to a HTTPSYS service.

Someone I trust to know what he is talking about, in the Danish Delphi group, mentioned that about the ADO, so I tried with SDAC in stead. It works on Localhost, but as it is just a trial (i dont want to pay for something I do not need), it won't run on machines without the IDE / Delphi installation. I've tried various proposals to copy different BPL files over which should allow it to run, but never managed to make it work. As part of the things I went through, I tried to compile my testprogram with runtime libraries, but got an error in one of the IW components. I do not recall which but will get back to you as soon as I see it again.

I'll try your proposals as well and let you know if / when I got it working.

Thanks.
Hi Alexandre,

I have tried your proposals, and with ServerController.ComInitialization set to ciMultithreaded, it works if I also use my own name/password for the service logon. I installed the HTTPSYS service on the SQL server.

I now need to have a domain user created who can login as a service, and are in the SQL Reader/Writer AD-group, but cannot login as a windows user on the server.

By comparing the two applications, the EXE as a service on the SQL server, and the DLL as a ISAPI under IIS 10 on the webserver, it is true that the service is much faster to respond and to start. Though it is a simple test and response times are quite low, it is still noticeable. The service is quicker.

Thanks for your help.