Hi,

Today I remebered that I saw these 2 variables and I thought I would take advantage of this stuff. I have some fields set their default to CURRENT_USER, CURRENT_COMPUTER and I was expecting that they will be filled in with UserName/ComputerName. In a client/server scenario this is not the case ... so they are useless. Obviously the help file must define these (maybe others) better, because I don't know what their purpose might be.

regards
Lucian

Lucian


I'm going to ask a silly question here - does each user have a separate login built into ElevateDB?

CURRENT_COMPUTER I would expect to be the server in a c/s environment.

Roy Lambert [Team Elevate]

>CURRENT_COMPUTER I would expect to be the server in a c/s environment.

Well, Roy ... I still consider myself a novice with ElevateDB (and probably never was an expert with DBISAM either ... so, most of the time when I do something new, I go to the help file. In the above case the help file only mentions "Returns the current computer's name as a string.". And because what happens in c/s env is indeed what you expect, that's why I said it's useless (I should've been more precise and said "in c/s environment"). I can't see in c/s mode how can this information be of any help.

I guess my beef is purely with the help file which I found these few last days very week, hoping it would get reviewed rather sooner than later and that other people resorting to the help file like me, will find it really-really usefull. So far I give Tim a mere "C" mark on it (or in other systems a merely 5-6 out of 10).

From a practical p.o.v I would probably like if the above functions would return in a c/s mode client's computername, username.

Best regards,
Lucian

Lucian


Since I haven't written the code, and haven't bought the source I'm only guessing from what it says in the OLH.

<<I guess my beef is purely with the help file which I found these few last days very week, hoping it would get reviewed rather sooner than later and that other people resorting to the help file like me, will find it really-really usefull. So far I give Tim a mere "C" mark on it (or in other systems a merely 5-6 out of 10).>>

You must be used to some very very good help files. I compare Tim's with one's such as CodeGear's D2006 OLH, TMS Software's OLH or PurposeSoft's HTMLEdit OLH and believe me, whilst not perfect, Tim's scores much higher than a "C".

Also, if someone points out an error or an area that requires clarification, its much more probable that the OLH will be revised for the next build.

One thing that Tim will suffer from is he wrote the software, he knows what it should do and it can be very hard to explain for a second party who doesn't have that experience. You think there are areas of the OLH that are very weak. It would be helpful if you could point these out - regard yourself as part of the review process

If there are parts of ElevateDB that don't do what you think they should post a suggestion to the suggestions ng. Tim keeps these in a pile (last time I asked it was about 3 inches thick) and does take notice of them. The small fact that he hasn't implemented all my suggestions / requests is just because he like to annoy me!

Finally - you didn't answer about logins for users......

Roy Lambert [Team Elevate]

>I'm only guessing from what it says in the OLH

The OLH doesn't mention anything about the information being valid only for a certain environment.

>You must be used to some very very good help files

Beside my MSDN stuff, this is the only help file I use these days.


>I compare Tim's with one's such as CodeGear's D2006 OLH

I was too harsh I think. Yes, I can not compare it with Delphi's mumbo-jumbo.


>It would be helpful if you could point these out - regard yourself as part of the review process

I'll try I guess...


>Finally - you didn't answer about logins for users......

No, I didn't. Thanks anyway
Lucian

I went quickly through the help file and couldn't really find big problems. It all seems clearly explained

The thing is, most times I actually encountered a problem and tried first the OLH, that's when it wasn't clear enough for me. I looked back in the SQL forum and I can pinpoint about 4 or 5 help (old) issues, I don't know if Tim already has this in his pile. The stuff really doesn't interest me anylonger and I don't know how bad/important these are. I suppose better OLH will help other newbies like me.

***

Some CURRENT_XXX functions may give different results in c/s mode than in non c/s mode. However the OLH doesn't say the environment matters.


DROP TABLE. Can not drop table that has foreign key(s) itself. Even though the OLH says this is the expected behavior, this is also non-standard deviation and should be marked as such or fixed in the engine. Tim said a fix is coming.


5.42 CREATE TABLE, 5.43 ALTER TABLE, 7.5 DECLARE are never explaining what <DefaultExpression> might look like. Perhaps this is clear for some d/b gurus, it was not clear for me when I looked it up. It will be enough explaining it in one place.


Reverse engineering a database produces different COLLATION output than what the help file says (not quoted versus quoted). I know it doesn't matter when that stuff runs. It does matter when you alter tables, reverse engineer AND COMPARE old-new scripts. In my case when all is fine I need 100% match, otherwise I waste time trying to see what went wrong. I also very much dislike inconsistencies.


I am not sure if this is still valid: I was advised in the past that in something like
"intgenexp" INTEGER GENERATED ALWAYS AS 2 NOT NULL
I should skip the NOT NULL beacuse it is not probably ok. However the syntax of this column definition is very much correct if you look at the help file, so I guess either the engine must be fixed or the OLH.

Be assured I'll post any other issues I find, but can't predict when that will be

regards
Lucian

Lucian,

<< The thing is, most times I actually encountered a problem and tried first
the OLH, that's when it wasn't clear enough for me. I looked back in the SQL
forum and I can pinpoint about 4 or 5 help (old) issues, I don't know if Tim
already has this in his pile. The stuff really doesn't interest me anylonger
and I don't know how bad/important these are. I suppose better OLH will help
other newbies like me. >>

I can't read your mind, so I don't have any idea what you're talking about
and can't possibly fix them. In general, OLH help issues usually get
fixed with each new build, but sometimes they might wait a build or two due
to the amount of time the PDF/OLH rebuilds take for all of the various
compilers.  The web site product manuals are always the most recent because
they are "live".

<< Some CURRENT_XXX functions may give different results in c/s mode than in
non c/s mode. However the OLH doesn't say the environment matters. >>

In general, SQL is *always* executed on the EDB Server, so with C/S
everything is always from the perspective of the server machine.  Just
remember that rule and you'll avoid any confusion.  However, I'll make a
note on these functions that this is the case.

<< DROP TABLE. Can not drop table that has foreign key(s) itself. Even
though the OLH says this is the expected behavior, this is also non-standard
deviation and should be marked as such or fixed in the engine. Tim said a
fix is coming. >>

Yes, a fix will be in build 4.

<< 5.42 CREATE TABLE, 5.43 ALTER TABLE, 7.5 DECLARE are never explaining
what <DefaultExpression> might look like. Perhaps this is clear for some d/b
gurus, it was not clear for me when I looked it up. It will be enough
explaining it in one place. >>

Noted, I will make a point to expand upon this.

<< Reverse engineering a database produces different COLLATION output than
what the help file says (not quoted versus quoted). I know it doesn't matter
when that stuff runs. It does matter when you alter tables, reverse engineer
AND COMPARE old-new scripts. In my case when all is fine I need 100% match,
otherwise I waste time trying to see what went wrong. I also very much
dislike inconsistencies. >>

The reverse-engineering always outputs optimal SQL in terms of making sure
to quote all identifiers, etc.

<< I am not sure if this is still valid: I was advised in the past that in
something like
"intgenexp" INTEGER GENERATED ALWAYS AS 2 NOT NULL
I should skip the NOT NULL beacuse it is not probably ok. However the
syntax of this column definition is very much correct if you look at the
help file, so I guess either the engine must be fixed or the OLH. >>

I will make a note about this in the manual.  I'm not sure when this was not
okay to use, but yes, you can use the above column definition in EDB now.
The generated columns are assigned before the constraints are checked, so
such a column will always be NOT NULL.

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com