Where have I gone wrong

[grindstone]

Maybe one of the expressions is too complex. I already ran into this issue sometimes in the past. Try this partitioned implementation:

Code: Select all

#Macro MakeProperty(fieldname, start, length, retType)
   #If retType = "s"
      Property tProduct.fieldname As String 'for reading
         Return Mid(this.record, start, length)
      End Property
     
      Property tProduct.fieldname(v As String) 'for writing
         Dim As String s
         s = v + String(length, " ")
         s = Left(s, length)
         Mid(this.record, start, length) = s
      End Property
     
   #ElseIf retType = "i"
   
      Property tProduct.fieldname As Integer 'for reading
         Dim As String s
         s = Mid(this.record, start, length)
         s = LTrim(s, Chr(0))
         Return Val(s)
      End Property
     
      Property tProduct.fieldname(v As Integer) 'for writing
         Dim As String s
         s = Str(v)
         s = String(4, Chr(0)) + s
         s = Right(s, 4)
         Mid(this.record, start, 4) = s
      End Property
     
   #EndIf
#EndMacro


Edit:
I vaguely remember there was some issue with incorrect submitted 'SPACE's here in the forum. Maybe it helps to delete and reinsert it or replace it with CHR(32).

[jj2007]

Mysterious. The Mid()= part is ok, it chokes on Left(v + String(length, " "), length)
More precisely,

Code: Select all

         ' tmp=String(length, " ")   ' chokes
         Mid(this.record, start, length) = Left(v + Space(length), length)   ' builds fine

So there is a problem with String(count, " "). And I found the cause, the UTF8 BOM in the *.bas file that my IDE sends: It causes trouble with String() - and with nothing else. Solution in this case:

Code: Select all

      Property tProduct.fieldname(v As String) 'for writing
         Mid(this.record, start, length) = Left(v + Space(length), length)  ' String() chokes but Space() is OK
      End Property

[grindstone]

OK, I've updated the code. Hope it works now.

[jj2007]

Works fine, thanks.

[Gablea]

Thanks to everyone who has help with this.

I shall try it tomorrow when I am at the office.


Just want to ask you all your options on the following

Is it possible to read the data from a network share?

I know there may be problem when I update the records but I could “lock” the tills for a few seconds while the new data file are being made. (Then would that turn it into a network based almost live system)

Or is it best to copy everything to the local drive and read the file locally

[paul doe]

...
Is it possible to read the data from a network share?

Yes, of course it's possible. But you'll have to implement it yourself, since FreeBasic doesn't have it 'out of the box'. You'll need to implement a sort of distributed database, with the data in one place and the consumer(s) in another, and implement an access protocol like ODBC. Or just use some database engine that has bindings for FreeBasic.

[sancho3]

I have not taken a close look at this but it would seem to me that Field = 1 should be added to the type to prevent padding issues.

[paul doe]

I have not taken a close look at this but it would seem to me that Field = 1 should be added to the type to prevent padding issues.

In this particular case, the padding in both my code and grindstone's is immaterial: mine reads each field from the file as binary and casts it into its proper place in the structure, and grindstone's read the entire record as a string and splices the fields into appropriate properties. Thus, neither of them needs the padding to be set to work correctly, since they aren't reading the structure directly from the file.

[sancho3]

Fair enough but at some point you are going to want to write back to that file (in theory).
I took a look at what you are doing in your code.
Isn't this a bit over done? Surely that file could be read with a simple structure of fixed length strings and a single get.
Essentially you are doing the same thing except in multiple steps.

[paul doe]

Fair enough but at some point you are going to want to write back to that file (in theory).
I took a look at what you are doing in your code.
Isn't this a bit over done? Surely that file could be read with a simple structure of fixed length strings and a single get.
Essentially you are doing the same thing except in multiple steps.

Yes, but this approach has a problem (which prompted the OP to ask for help): FreeBasic fixed-length strings inside a type are zero-terminated:

Code: Select all

type record field = 1
  name as string * 3
  phone as string * 12
end type

? sizeOf( record ) '' WTF!?

sleep()


And unfortunately, make the 'straightforward' approach unworkable in this case...

[Gablea]

...
Is it possible to read the data from a network share?

Yes, of course it's possible. But you'll have to implement it yourself, since FreeBasic doesn't have it 'out of the box'. You'll need to implement a sort of distributed database, with the data in one place and the consumer(s) in another, and implement an access protocol like ODBC. Or just use some database engine that has bindings for FreeBasic.

I’ve tried to use MySQL but I’ve never seem to got it to work right. But this new way seems much better. And if the files was stored in a RAM drive then reading then should be very quick.

All I need to do now is work out how to update the findCashier function to use the code that has been provided to me on here. (Much appreciated by the way)

[jj2007]

if the files was stored in a RAM drive then reading then should be very quick.

No ram drive needed for such a tiny file - an ordinary harddisk is fast enough:

Code: Select all

Reading 2024 records took 708 µs
BarcodeNumber  00001293
posdescription VACUUM CLEANERS

[Gablea]

if the files was stored in a RAM drive then reading then should be very quick.

No ram drive needed for such a tiny file - an ordinary harddisk is fast enough:

Code: Select all

Reading 2024 records took 708 µs
BarcodeNumber  00001293
posdescription VACUUM CLEANERS

Some of the systems have like 16,000 or more items so should that not make much effect either?

[caseih]

Correct. A RAM drive will be of no benefit for such a small amount of data (if each item was 1024 bytes or less, that's no more than 16 MB for 16,000 records). Think about it: it still takes the same amount of time to copy it from the spinning disk into the ram disk as it would for your program to simply read it all into memory when it starts. The RAM drive is just a complication.

[Gablea]

Cool. I’ll be spending tonight to see if I can get the system to read the data now.

Just hope I can integrate the code you both have provided into my app to support the new method :)

Wish me luck :)