Why jBASE is allowing Blank Space as Record ID?

[Malai]

Hi All,

Please see my sample program.
jBASE is allowing me save a record with null ID. Is there any specific
reason for this? or its a bug in jBASE?

Command->
0001 PROGRAM TEST.NULL
0002
0003 OPEN "XYZ" TO F.XYZ ELSE STOP "OPEN ERROR"
0004 WRITE.DATA = "HELLO WORLD"
0005
0006 ID = " "
0007
0008 WRITE WRITE.DATA TO F.XYZ,ID ON ERROR
0009 STOP "ID ERROR"
0010 END
0011
0012 STOP

Could anyone please clarify me?

Tks
Malai
jBASE4.1 on Aix5.2

[Gary Calvin]

A space is not a null. There's no reason why it shouldn't be a valid item id. It can even be a file name. Whether it's a wise choice for an item id or file name is another question.

-Gary-

[Kevin Bilbee]

That is not a null ID it is a char 20 and spaces are valid characters in a
record ID. Probably a bad idea to have whitespace as a record ID though.
Jbase your code should check for this situation and not allow it.

Kevin Bilbee

[Jim Idle]

________________________________

From: jB...@googlegroups.com on behalf of Kevin Bilbee
Sent: Tue 5/9/2006 7:30 AM
To: jB...@googlegroups.com
Subject: RE: Why jBASE is allowing Blank Space as Record ID?

That is not a null ID it is a char 20 and spaces are valid characters in a
record ID. Probably a bad idea to have whitespace as a record ID though.
Jbase your code should check for this situation and not allow it.

Interestingly, we used to throw out things that looked like mistakes such as a "" as an item ID and were badgered so much to not do this, that we stopped. A single space though is something that jBASE would have no way of knowing was a 'bad' ID or not, so it cannot start arbitratilly deciding waht is good or bad... that was MY job! ;-)

Jim

[Peter Mowatt]

The null ID is not unique to jBase. It is a valid ID in most
environments. If no null record ID is wanted, then test for it in the
program.

[Daniel Klein]

A 'null' item-id is not valid in a directory, only in a hashed file.

Dan

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of

[T.Turkington]

If this is something you don't want you may add a PREWRITE trigger to the
file that checks for a recordkey = "" and aborts accordingly - I have to
agree that I've never quite understood why anyone would want a NULL id,
but... Note: to delete from jsh/jql you need to DELETE FILE '' - SELECT
FILE ''/DELETE FILE doesn't work; i.e.:

jsh tom ~ -->SELECT TIMESHEETS ''

1 Records selected

jsh tom ~ -->DELETE TIMESHEETS
0 record(s) deleted.
jsh tom ~ -->DELETE TIMESHEETS ''
1 record(s) deleted.

Tom

[Simon Verona]

Interesting question, I'm just a bit lazy to find out myself...

Can you set a "global" trigger ? ie a trigger that runs on all files?

Regards
Simon

=======================================
Simon Verona
Dealer Management Services Ltd
Stewart House
Centurion Office Park
Julian Way
Sheffield
S9 1GD

Email: si...@dmservices.co.uk
Tel: 0870 080 2300
Fax: 0870 169 6747

[Malai]

Thanks All, for your valuable discussion.

There are many workarounds to avoid this type of situation.

I feel jBASE should not allow an empty space as a record ID.

Tks
Malai

[Charlie Noah]

Malai,

There's a big difference between a space and a null ID. Neither is
a good idea, but historically the MV (aka Pick) model has permitted
that bit of "rope". Jbase is just being faithful to the model, as well
it should. There are countless ways you, as an applications developer,
can shoot yourself in the foot. Jbase allows you that power, expecting
that you will program judiciously. I much prefer this over a system
that applies all kinds of constraints, thereby limiting the developer
from doing pretty much anything desired. As a developer for 28+ years,
those constraints would be unacceptable to me. </soapbox>

Regards,
Charlie Noah
Inland Truck Parts

[Daniel Klein]

Not really.

A trigger could be written for some generic task, but it would have to
purposely be assigned to every file on the system.

Why would you want to do such a thing?

Dan

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of
Simon Verona
Sent: Tuesday, May 09, 2006 12:58
To: jB...@googlegroups.com
Subject: RE: Why jBASE is allowing Blank Space as Record ID?

Interesting question, I'm just a bit lazy to find out myself...

Can you set a "global" trigger ? ie a trigger that runs on all files?

Regards
Simon

=======================================
Simon Verona
Dealer Management Services Ltd
Stewart House
Centurion Office Park
Julian Way
Sheffield
S9 1GD

-----Original Message-----

[Simon Verona]

I've had several reasons in the past for considering doing this. The one I
had in mind at the moment is to create a separate "audit" file recording all
updates to records - recording the timestamp and the user id who did the
update. I have other ways to do this, but a trigger would be a useful
way!

Regards
Simon

=======================================
Simon Verona
Dealer Management Services Ltd
Stewart House
Centurion Office Park
Julian Way
Sheffield
S9 1GD

Email: si...@dmservices.co.uk
Tel: 0870 080 2300
Fax: 0870 169 6747

[T.Turkington]

To prevent crap in the recordkey for one...

[Daniel Klein]

Interesting notion, but a single line in the application could accomplish
the same thing, without the overhead of firing a trigger for every database
'write'.

[Jason.Sh...@cexp.com]

The same type of DBMS managed record id rules could be used to implement
automatic sequential id's, too, which would be a nice feature for jBASE,
IMO

[T.Turkington]

A single line in which application? There are a couple hundred 'write'
statements in our application. Not that this is really a problem in our
application, but records can be created any number of ways. The idea for a
'global' trigger would be to prevent this particular type of 'error'
regardless of the source. Malai (and I) can attest to the fact that NULL
record id's do get created. Regarding 'overhead' well cpu's are relatively
fast these days; I'm guessing Transaction Journaling/Distributed
Files/Indexed files must have a similar 'overhead' without any noticable
complaints from users...

[Jim Idle]

Doing things like this at the application level is a really bad idea as you will start to limit the system performance to application level programming such as all the group locking that would be required for instance if you saved these things in a hashed file and node locking in the file system and so on.

In this particular case, this is what Transaction Journaling is for.

In general triggers are for application level functionality (say a poor mans referential integrity) and even then you should consider carefully whether a trigger is the correct thing.

Jim

________________________________

From: jB...@googlegroups.com on behalf of Simon Verona
Sent: Thu 5/11/2006 12:48 PM
To: jB...@googlegroups.com
Subject: RE: Why jBASE is allowing Blank Space as Record ID?

[Jim Idle]

________________________________

From: jB...@googlegroups.com on behalf of T.Turkington
To prevent crap in the recordkey for one...

No - that is an application bug if it can happen! If a bucket has a hole in it you patch the hole (or get a new bucket), you don't catch the water in a complex system of pipes and pumps to put the water back in the bucket!

Jim

[Jim Idle]

Auto sequential IDs would have been a reasonable idea.

John did produce a UNIQUEKEY function for 4.1 though that generates the same thing without needed to do a READU, +, WRITE. What you need at Corporate Express is a bloke that knows a bit about jBASE ;-)

Jim

________________________________

[Jim Idle]

________________________________

From: jB...@googlegroups.com on behalf of T.Turkington
Sent: Thu 5/11/2006 8:57 PM
To: jB...@googlegroups.com
Subject: RE: Why jBASE is allowing Blank Space as Record ID?

> A single line in which application? There are a couple hundred 'write'
> statements in our application. Not that this is really a problem in our
> application, but records can be created any number of ways. The idea for a
> 'global' trigger would be to prevent this particular type of 'error'
> regardless of the source. Malai (and I) can attest to the fact that NULL
> record id's do get created. Regarding 'overhead' well cpu's are relatively
> fast these days; I'm guessing Transaction Journaling/Distributed
> Files/Indexed files must have a similar 'overhead' without any noticable
> complaints from users...

Transaction logging is a system level function and has an overhead of about 30% throughput. If you start to do the same thign with triggers in BASIC at the applciaiton level your overhead will be very much more than that!

More importantly though, you argument is falacious. What would the application do if it trigger discovered a bad ID? Such a thing is an application bug and really you just need to fix it if you have it.

Jim

[Charlie Noah]

Well said!

Charlie Noah

[T.Turkington]

i wasn't suggesting a complex system - nor do I disagree about your bucket fixing plan - but this thread started with Malai's question about a NULL recordkey.  My understanding is there is currently no way to prevent this at a global level for hash files (feel free to correct me) and a 'global' trigger would allow a developer to override this...  and perhaps the problem is that Malai doesn't know which buckets in his system have this particular leak...  if there was a 'global' trigger and a bad recordkey was captured, SYSTEM(1000)/LOGON/PORT/DATE/TIME info could be recorded to help id which bucket has the leak...  obviously Malai can do this now by adding a siimilar trigger to the specific file that had the NULL id, but a 'global' trigger would allow you to do this ifever the problem occured; i.e. could be used preemptively rather than postfacto.  Seeing as WRITE currently must address in-file triggers/distributed files/index maintenance/trans journaling etc, I don't understand why a 'global' trigger would add that much 'overhead' or 'complexity' to the process.

 

That said, I should add that I would personally never use this particular type of trigger, unless I ran into a situation where a number of files were randomly encountering this particular problem.  Admittedly, I have encountered NULL item id's from time to time and have just had to scratch my head in wonder as to 'where' they came from.  I would also never suggest a global trigger be used indiscriminately or do anything complex (unless someone wanted to do their own trans journaling) but I can't imagine doing some simple validations on recordkey being that big a deal...

 

Tom

 

-----Original Message-----
From: Jim Idle [mailto:jB...@googlegroups.com]On Behalf Of Jim Idle
Sent: Friday, May 12, 2006 5:17 AM
To: jB...@googlegroups.com
Subject: RE: Why jBASE is allowing Blank Space as Record ID?

 

[T.Turkington]

Per my most recent post (a minute ago), in response to 'what would the application do...', well it could help id which bucket is leaking...

 

But if I may change the arguement for a 'global' trigger a little towards 'more wishful' thinking; i.e. a 'global' error handler/trigger...  Recently we encountered a problem where jbase hash files were being locked at the Windows OS level by some 'unknown' remote process.  This would throw a ERRMSG 13 (Data is Invalid) error if a READ/WRITE were attempted on a file that had been opened prior to the lock being placed by Windows, and our programs would subsequently crash.  The 'remote' process appeared to be a Spyware or Backup process where one file at a time in the data directory would be locked, and the length of the lock appeared to be relative to the size of the file.  These locks were occuring approx every 75 minutes.  Generally we do not write (but probably should) our BASIC code with ON ERROR statements unless we anticipate one.  It took me approx 6 days to id the fact that the files were locked coincidental with these ERRMSG 13's.  It was driving me kind of crazy because one minute it would be one file, the next another, and then the problem would disappear entirely for an hour or so... The site where this was occurring is pretty much a 24/7 operation, and by day 6 the bosses of the bosses of the people I normally deal with were calling me...  In any event, it would've been, and would be, very helpful to've been able to temporarily install some sort of 'global' error handler that would've circumnavigated the data loss/application crashes that occured as a result of this.  I don't know what's on the horizon in jb4.x but may I offer this as food for thought...

 

Tom

-----Original Message-----
From: Jim Idle [mailto:jB...@googlegroups.com]On Behalf Of Jim Idle

[Jim Idle]

You can find out a lot more information in jBASE 4.1 about such things in fact. However you would still need the ON ERROR clauses to use it without affecting the live performance in this case. It is one of the new SYSTEM() functions I believe and tells you all about the calling PATH to the current line and so on.

However a global error handler isn't a bad idea at all of course (universal on error) but I do not believe it is in 4.1. I would submit it as an enhancement request and go through the Vogon firelighter cycle.

Jim

[Jason.Sh...@cexp.com]

On jBASE 3 we set JBASE_WARNLEVEL appropriately and jBASE logged errors to the jbase_error_trace file, which enabled us to identify issues with the app that would not have been brought to our attention otherwise (divide by zero, uninitialized variable, etc.). We would routinely look in this file for errors, and correct the application code accordingly. Logging to this file, IMO, would have been a reasonable place for such global error notifications, of course not as good a hook into a jBC routine, though.

 

But it seems in jBASE 4 that error_trace functionality was drastically reduced, and now all we see in jbase_error_trace are TJ activity logs. Ah well. Whoever’s listening…

 

---