> -----Original Message-----
> From: Colin Fraser [mailto:Colin.Fraser@...]
>
> I haven't got the full version so I am only guessing at what is
> going on...

It's nice to guess if you have 4 hours to deliver your application to the
client, for example.
;-)

> With more experimentation I have found that it doesn't matter
> what database
> you connect to as long as it is local, it seems to work...

Correct. Finding "InterBase SW Corporation v4 Groton Database Systems" (aka
ISC4.GDB) is the task of the server. The so-called "security database" (or
backdoor database) should reside on the main IB directory, whereas the
server lives in an inner directory, named "bin" usually. You shouldn't
connect to it as a general guideline.

> From this I gather that my use of the AlterUser function may have been
> incorrect. I assumed that if you connected directly to ISC4.gdb (even
> remotely) that it would work. But it seems that IBO tries to
> find ISC4.gdb
> itself somehow.

No, IBO doesn't do those tricks. In Windows, you could connect to the
remote registry and try to grab the location of the IB dir, but this isn't
necessary. IBO only fills parameters for an API call, defined in IB5 and
deprecated in IB6. More below.

> Does the AlterUser function just look for ISC4.gdb on the local pc and try
> and update that?

No, AlterUser is an API call defined in IB5 as "transitory". It means it
was introduced to help users but it was known it would be deprecated in
favor of something different. Borland warns you in the IB5 manuals that this
call will be made obsolete.

> So to conclude, if you want to update users remotely you have to
> use IB6 and
> the IBX services controls??

No, let me tell the story and maybe I will post it at my site in the
future: before v4, there was no ISC4.GDB neither ISC3.GDB, because the
server used the operating system's authentication... so what Ms does with
SqlServer is not new.
When v4 was introduced by Borland in 1994, they created ISC4.GDB because
they ported the server to Windows and our lovely Windoze 3.0/3.1 didn't have
any authentication neither a pw stored in an ini file. So, the
authentication became a task for IB. However, since
- Novell was in widely use and nobody had great experience writing console
NLMs,
- Windows was in rise and
- Windows users would demand a GUI for administering IB even on other
platforms,
Mark Duquette created the first Services API. Closed, unpublished and
secret. Only gsec and Server Manager knew the trick. The same
ISC_ATTACH_SERVICE entry point was present in the gds.dll that shipped with
D1 (IB4.0C) and REM_ATTACH_SERVICE in remote.dll, whose counterpart is
jrd8_attach_service in jrd.dll. The reason Borland hid the information is
that such API wasn't ready for massive consumption: it didn't define clear
parameters, it used some hacks, there were no "normalized" DPBs to return
info, etc. If the author told me that, I don't doubt. In fact, it accepted
parameters in the form of a string containing the options same as you write
them to call the equivalent command-line utility. I know because a Russian
person did the trick once.
From those times, you can find Borland's contribution to insecurity. This
lives inside jrd.dll in v4.0:
«
USER_NAMEGIDUIDPASSWDL isc4.gdb9zpoliticallycorrectUnknown QATEST_entrypoint
#%lu
»
The QATEST_entrypoint probably is the rogue self-destruction UDF that Q&A
requested to embed in the server. This lives inside ibserver.exe in v4.2:
«
USER_NAMEGIDUIDPASSWDL
isc4.gdb9z9zpoliticallypolitically9zcorrectWI-V4.2.1.328
»
From our external perspective, it was incredible that Borland didn't
publish the remote administration facility that could have been a selling
point, but the reason was the above paragraph. Borland did a good effort on
v4 releases. For good or bad, they introduced SuperServer, created remote
administration, defined a proprietary security database, deprecated GDML in
favor of SQL, moved the DSQL utility (it was a external facility, since GPRE
was previously the king through embedded SQL) into the engine so it became a
subsystem, etc.
Admins mostly wanted to manage users, so Mark introduced in IB5 three API
calls: add, delete and modify. No listing of users unless you connect to
isc4.gdb. These are the ones you are using through IBO. They aren't part of
the old Services API but a patch solution for customers. Server Manager uses
its own tricks, the same than in IB4.
In IB6, Borland did the [last?] effort on the engine. At the scale of the
small product, having replication, complete remote management, three
dialects and changes to the traditional garbage collection mechanism is no
task for the faint of heart. Since there were requests for enhanced
management and information returned by the engine, Mark turned to the mess
again and defined specific DPBs, byte parameters as in other API calls and
put in fashion the ATTACH, DETACH and QUERY calls that comprise the Services
API. This time it was published.
So far so good. I don't think that the Services API is intrinsically bad.
With time, it could have evolved and fix the rough edges. But on Dec-1999,
Borland crushed IB, top IB managers and some engineers resigned, Mark was
"reallocated" to the Windows Development Group, development halted and the
rumor mill said (with a good chance to be exact) that the v6 release would
be void, so latest IB would be IB5. Around March, Mark Duquette left
Inprise, so the Services API author and specialist was out.
We know what happened in last year and how the community was divided when
ISC didn't happened in Jul-1999. When the backdoor was discovered, Borland
was warned but they didn't provide feedback. After the guerrilla caused by
Jim's opinion on the backdoor's origins, Mark decided to cut down any
relation with the engine, so he's no longer a possible volunteer. If the
Services API is going to be fixed or enhanced, someone should undertake the
task. Jeff is convinced that there's a bug while using it to produce remote
backups, so hopefully R&D inside Borland will take a peek.

So, little grasshopper, do not believe that all things are straightforward
or that they have a glorious past or raison d'être.

C.