#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).
Last edited by grindstone on Sep 21, 2018 14:28, edited 1 time in total.
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:
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
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
Gablea wrote:...
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 wrote: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.
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.
sancho3 wrote: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:
Gablea wrote:...
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)
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.
