Randomly write data to a file
Wouter Huygen
... for random" and "Put" and "Get" statements.
But can I also use his method to sequentially store records, array's and
different types of records? I have a lot of data in different variables that
I want to store in just one file and not having to create a different file
for each type of variable/record.
For instance:
Dim RecordVar as RecordType
Dim StringArray(0 to NrOfString) as string
Open "file.dat" for random as #1
Put #1,1,RecordVar
For I=0 to NrOfStrings
Put #1,????, StringArray(I)
next
close #1
Joe "Nuke Me Xemu" Foster
You could use Get and Put with a Binary file, or Input#, Line Input,
Print, and Write with a text file. Also check out FreeFile and the
Open statement's Len option.
--
Joe Foster <mailto:jlfoster%40znet.com> Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
Terry Austin
sure that none of your string variables are longer than the record
length. This could be tricky if you're using variable length strings
that have no practical (or enforced) limit on how long they can
be.
This is why I finally learned to use databases. For what you're
describing, saving everything to a database created by code
on the fly is perfect.
Terry Austin
Shane_A
When considering the storage requirements for your application, I guess you
have to ask yourself a couple of questions -
1. Do I want/need "Variable-Length" fields?
2. Do I want to use an existing "Database Engine" or write my own routines
to handle data storage and manipulation?
To answer the second question first, I suppose most people today chose to
use one of the numerous database engines that are available thus avoiding
the intricacies of having to write their own database format.
For myself, I am from an era before such niceties as DBase (let alone more
recent "engines") so I will always opt for writing my own data handler
routines. I realise this is a very old way of thinking however I still
prefer the unsurpassed control and lightning speed I have by choosing this
option - YES, writing your own well-structured database routine will ALWAYS
process data quicker than any of the off-the-shelf database engines! (I have
won many bets over the years on this point alone!) The greatest draw-back
can be the time it takes to develop your own format and of course -
integration with other applications.
Assuming you decide to "roll your own" then you must now consider my first
question regarding Variable Length Fields. If you decide on the easy option
and choose Fixed Length Fields then all that's required is to go ahead with
something like -
Private Type CustomerData
blToBeDeleted As Boolean
iCustNumber As Integer
sFirstName As String * 30
sLastName As String * 30
sAddress1 As String * 40
sAddress2 As String * 40
End Type
Global rCustomer As CustomerData
As the record-size of the above example would always be equal to 144
characters, it would be easy to write your own database format to access
individual records, either sequentially or randomly. (TIP: You could use
ListBoxes to store your Index/Key Field Data, such as "iCustNumber", and the
ListBox ItemData to store the Record Number of where the complete record may
be found within your database).
Obviously Variable-Length Fields require much greater programming overhead
than Fixed-Length Fields and you then need to move to using Binary Access
Files, however once you get into developing your own code it is easy to make
it re-usable so it becomes easier the next time. To give you an insight,
you need to use what I call "Field Length Variables" at the beginning of
each field to declare how many bytes the following field contains. You can
then use code like -
Get #iInput, , iLen 'How long is the following Variable Length Field going
to be?
sCustomerName = Space$(iLen) 'Prepare the String Variable to receive the
data.
Get #iInput, , sCustomerName 'Load the Variable with the stored data.
One of the greatest advantages of Variable Length Fields is of course the
smaller size of the overall database. As hard drives have long since
expanded beyond 10 Megabytes, I feel this advantage is not worth the extra
programming overhead.
To go into greater depth on this entire topic is probably beyond the scope
of this forum, however I would encourage you not to just take the easy way
out but to consider your options as you are obviously at the early stages of
your programming career.
Now I guess I'll just wait for the inevitable barrage of abuse from the
"Database Engine" users out there! :-)
Cheers,
Shane
"Wouter Huygen" <huy...@od35.nl> wrote in message
news:9n1z7.161$H76....@pollux.casema.net...
J French
wrote:
>Wouter,
>
>
>Now I guess I'll just wait for the inevitable barrage of abuse from the
>"Database Engine" users out there! :-)
>
>Cheers,
>Shane
>
Jeez - there is someone else out there who can code !
Congratulations Shane - my only comment is that if possible convert
the data to Human Readable Format - like storing lots of small INI
files in one big file.
Actually I sort of lied - I've spotted about two others who still
understand the importance of 'owning' ones data.
Joe "Nuke Me Xemu" Foster
> Jeez - there is someone else out there who can code !
Yeah, well, life's too damned short to waste it writing my own
transactioning, multi-user concurrency control, and reporting
white-elephant-ware, so there.
> Congratulations Shane - my only comment is that if possible convert
> the data to Human Readable Format - like storing lots of small INI
> files in one big file.
>
> Actually I sort of lied - I've spotted about two others who still
> understand the importance of 'owning' ones data.
To fully appreciate databases, most people must first lose all
their data because of a bug in their file I/O code. Backups
and archives don't help if it takes too long for a corruption
problem to fully metastasize...
--
Joe Foster <mailto:jlfoster%40znet.com> On the cans? <http://www.xenu.net/>
Shane_A
> To fully appreciate databases, most people must first lose all
> their data because of a bug in their file I/O code. Backups
> and archives don't help if it takes too long for a corruption
> problem to fully metastasize...
>
What? - FoxBase, DBase, JET, Access and all the others DON'T have bugs in
them so there's no way someone could lose their data when using one of these
engines?
At least with "rolling your own" you can incorporate some pretty
sophisticated "Detection & Recovery" routines as you have intimate knowledge
of the database structure. This is what I have incorporated in all of my
apps and it works fine for me. :-)
Don't get me wrong, I am not criticising those who don't want to, (or have
never learnt how to), write their own database handler routines - I guess
I'm just a control freak and like the non-compromised power that is
available when using my own structure.
Cheers,
Shane
Joe "Nuke Me Xemu" Foster
> What? - FoxBase, DBase, JET, Access and all the others DON'T have bugs in
> them so there's no way someone could lose their data when using one of these
> engines?
There's less chance of data loss with them than if I tried rolling
my own at this point. Perhaps you just do more deadline-free "green
field" development than I.
> At least with "rolling your own" you can incorporate some pretty
> sophisticated "Detection & Recovery" routines as you have intimate knowledge
> of the database structure. This is what I have incorporated in all of my
> apps and it works fine for me. :-)
>
> Don't get me wrong, I am not criticising those who don't want to, (or have
> never learnt how to), write their own database handler routines - I guess
> I'm just a control freak and like the non-compromised power that is
> available when using my own structure.
Does that include multiuser transactioning support? How about outside
connectivity, perhaps through ODBC or OLEDB? Why re-invent the report
writer?
--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
sa...@omegatechware.hypermart.net
<j...@bftsi0.UUCP> decided to enlighten us with :
>Does that include multiuser transactioning support? How about outside
>connectivity, perhaps through ODBC or OLEDB? Why re-invent the report
>writer?
Joe,
Not trying to butt heads with you, as I highly respect your
opinions (from at least four years back), but I hardly ever use the
built in data access objects in VB. When I do, it's usually to convert
an MDB to my own format.
My reason for this is twofold. Control over exactly how things
are done is one factor, but the main consideration is DLL hell (Say no
more. Wink, wink, nudge, nudge). I have quite a few methods that I use
that make my home grown databases just as, or quite frequently, more
efficient than Jet or the others. Remember, Bill the deity smiled upon
us when he said "Yea, and unto thee I have given your hands that
typeth the holy command of ... Lock.". Adding a timestamp field to
your UDTs for record synch is fairly trivial as well.
Data binding can be a little bit of a 8!7(#, but I've always
been a keyboard-centric person, so setting a few properties with the
mouse seems like a commitment. Libras like myself and programmers all
over the world have learned to fear that word. <g>
I'm not taking sides (assuming they exist at this point). I
just had too much amaretto in my coffee, and being longwinded in
addition, figured I'd interject a little insanity into this thread.
>--
>Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
>WARNING: I cannot be held responsible for the above They're coming to
>because my cats have apparently learned to type. take me away, ha ha!
Respectfully yours ... and cheers!
J.
PS - love the sig!
Jeremiah D. Seitz
Porch karaoke king and the guy who runs with 8< scissors >8
Omega Techware
http://omegatechware.hypermart.net
Shane_A
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote:
>
> There's less chance of data loss with them than if I tried rolling
> my own at this point. Perhaps you just do more deadline-free "green
> field" development than I.
>
is it a lack of ability to roll your own? As far as "deadline-free" I
suppose I'm experienced enough to (usually) quote a realistic deadline in
the first place. It sounds to me like you're just trying to be one of those
people who want to make themselves seem more important because they have
self-imposed unrealistic deadlines - try settling down a little, you might
just live a bit longer :-)
>
> Does that include multiuser transactioning support? How about outside
> connectivity, perhaps through ODBC or OLEDB? Why re-invent the report
> writer?
>
Oh gee, now you've impressed me - you've used all the big words in just one
sentence!
You need to remember that Multi-User Transactioning is by no means new and
was something many of us had to deal with when writing Fortran code on DG
MV-8000's - years before a single database engine existed!
As far as outside connectivity is concerned - YES, you have a valid point.
Outside applications cannot "automatically" scan my database structures and
extract information for their own purposes, however I can "expose" data in
anyway required should the situation be called for and can easily (and more
powerfully) extract data from ANY existing off-the-shelf database.
Finally, "Why re-invent the report writer?" - Why be confined by it? Surely
you can't be totally satisfied with the limitations of most report
generators included with popular database packages? Most seem to have been
provided as an after-thought which is why you usually have to buy the "Full
Version" to obtain the results you really want.
At the risk of sounding repetitive, rolling-your-own code to handle your own
database requirements provides unparallel flexibility, speed and overall
power. Just because the majority of people choose to buy off-the-shelf
products thus burdening their applications with additional baggage and
performance degrading add-ins, doesn't mean it's the only remaining option.
I'm all in favour of up and coming programmers retaining basic skills, not
just becoming "Object" assemblers. Afterall, someone has to remain skilled
enough to write the "Engines" and the "Objects" in the first place!
Cheers for now,
Shane
J French
wrote:
<snip>
>I'm all in favour of up and coming programmers retaining basic skills, not
>just becoming "Object" assemblers. Afterall, someone has to remain skilled
>enough to write the "Engines" and the "Objects" in the first place!
I wholeheartedly agree - personally I believe that MS have made a
concious effort to de-skill programmers.
>
>Cheers for now,
>Shane
>
>
>
>
Frank Adam
wrote:
I wouldn't go as far as blaming MS for this.
Its' progress with production speed in mind and is there in almost
every trade or profession in some form or another.
Regards, Frank
J French
wrote:
>On Tue, 23 Oct 2001 10:43:42 GMT, je...@iss.u-net.com (J French)
>wrote:
>
>>>I'm all in favour of up and coming programmers retaining basic skills, not
>>>just becoming "Object" assemblers. Afterall, someone has to remain skilled
>>>enough to write the "Engines" and the "Objects" in the first place!
>>
>>I wholeheartedly agree - personally I believe that MS have made a
>>concious effort to de-skill programmers.
>>
>I wouldn't go as far as blaming MS for this.
>Its' progress with production speed in mind and is there in almost
>every trade or profession in some form or another.
>
Just because something is prevalent does not mean that it is not
deliberate. VBX was *very* deliberate - in VB5+ MS backed off.
BTW saw your posting in the Delphi NG - I'll Email you a load of my
crap when you are ready.
Regards - Jerry
>
>
>Regards, Frank
Joe "Nuke Me Xemu" Foster
> "Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote:
> >
> > There's less chance of data loss with them than if I tried rolling
> > my own at this point. Perhaps you just do more deadline-free "green
> > field" development than I.
> >
> Hmmm, when you say "at this point" does that mean you lack the confidence or
> is it a lack of ability to roll your own? As far as "deadline-free" I
> suppose I'm experienced enough to (usually) quote a realistic deadline in
> the first place. It sounds to me like you're just trying to be one of those
> people who want to make themselves seem more important because they have
> self-imposed unrealistic deadlines - try settling down a little, you might
> just live a bit longer :-)
That's a load of crap, and you know it. The Jet and xBase database engines
have been pounded on by who knows how many developers and end-users for
years, which amounts to sagans and sagans of hours of real-world testing!
Just how thoroughly tested is your data file code? And all those "big
words"? Those represent additional functionality I can deliver, right now,
without additional work on my part. As for lack of ability, I've already
long ago written my own multi-user persistent object store, and I think I'll
live more than a bit longer if I never have to think about porting it to
Windows!
Anyway, if you're so against "burdening" your applications with "additional
baggage and performance degrading add-ins", WTF are you doing using Visual
Basic? "Real Programmers" use assembly language, since even C burdens one's
applications with too much "additional baggage and performance degrading
add-ins" like printf()! Microsoft BASIC -- what are you, some sort of wuss?
J French
<j...@bftsi0.UUCP> wrote:
>"Shane_A" <shan...@bigpond.com> wrote in message <news:Oc5B7.154$c5....@newsfeeds.bigpond.com>...
>
>> "Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote:
<seriously snipped>
Cmon Joe, you I and some others know that there are 'horses for
courses' - it is absurd distributing dozens of controls just to get a
little file access going.
It is also not economically viable to write a re-implementation of
CICS for every app.
What Shane and I were whinging about is that programmers seem to have
lost the ability to open a simple file.
This I seriously consider 'de-skilling', and from your last post which
basically said 'been there done that' - I suspect that you agree.
Much of programming is pragmatism - and there are some trends that are
disturbingly 'non-pragmatic'.
W.E. (Bill) Goodrich, PhD
je...@iss.u-net.com (J French) writes:
[...]
> What Shane and I were whinging about is that programmers seem to have
> lost the ability to open a simple file.
> This I seriously consider 'de-skilling', and from your last post
> which basically said 'been there done that' - I suspect that you
> agree.
So do I.
> Much of programming is pragmatism - and there are some trends that
> are disturbingly 'non-pragmatic'.
I would go beyond that to 'anti-pragmatic'. And one of the major
sources of that trend is easy to find - academia (and this coming
from a Ph.D. <-;). In the academic propaganda, the opposite of
'pragmatic' is 'disciplined' - with the 'undisciplined' (pragmatic)
approaches exaggerated to the point of parody.
Certain manufacturers are also a significant source of the trend,
playing to the academic prejudices and business buzzwords in order to
foster dependence on their tools. A programer with good,
tool-independent skills is not a captive.
We've seen the results of these trends in various groups - people who
adamantly parrot the "company line" without seeming to understand the
relevant issues.
--
W.E. (Bill) Goodrich, PhD
*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * ctgce...@earthlink.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*
Joe "Nuke Me Xemu" Foster
> On Wed, 24 Oct 2001 11:11:28 -0700, "Joe \"Nuke Me Xemu\" Foster"
> <j...@bftsi0.UUCP> wrote:
>
> >"Shane_A" <shan...@bigpond.com> wrote in message <news:Oc5B7.154$c5....@newsfeeds.bigpond.com>...
> >
> >> "Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote:
> <seriously snipped>
>
> Cmon Joe, you I and some others know that there are 'horses for
> courses' - it is absurd distributing dozens of controls just to get a
> little file access going.
"Dozens of controls"? Where did this come from, after all the code I've
posted over the years showing how to ditch bound controls and use the
native built-in controls with databases?
> It is also not economically viable to write a re-implementation of
> CICS for every app.
>
> What Shane and I were whinging about is that programmers seem to have
> lost the ability to open a simple file.
Perhaps, but IME data files can be breeding grounds for very nasty bugs,
while using DAO and Access databases usually gives the biggest bang for
the boss' buck. Why reinvent the hierarchical database again and again?
Also, if/when you outgrow Access, your skills and data can be transferred
to the "big guns" like SQL Server, Sybase, or DB2.
http://userpages.umbc.edu/~khoo/410/410_db_tutor.html#3
> This I seriously consider 'de-skilling', and from your last post which
> basically said 'been there done that' - I suspect that you agree.
Remember, I also basically said 'don't wanna do it again'!
> Much of programming is pragmatism - and there are some trends that are
> disturbingly 'non-pragmatic'.
Such as the FileSystemObject? Don't get me started!
--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
Shane_A
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:tte12rk...@corp.supernews.com...
>
>
> That's a load of crap, and you know it. The Jet and xBase database
engines
> have been pounded on by who knows how many developers and end-users for
> years, which amounts to sagans and sagans of hours of real-world testing!
> Just how thoroughly tested is your data file code?
>
susceptible to failure than any of the commercially available engines. This
can be stated because my code has remained fundamentally the same for many
years and is used in many real-world applications daily. Granted, my code
hasn't been tested for a period "which amounts to sagans and sagans of hours
of real-world testing" however there does come a time when you can feel
confident that your code is as error free as is possible notwithstanding the
limitations of the compiler and operating system.
> And all those "big words"? Those represent additional functionality I
can deliver, right now,
> without additional work on my part.
>
What, and without those wonderful database engines, I can't?
Like most programmers I write "re-usable" code which can then provide a
means of constructing functional applications in the shortest period of
time.
>As for lack of ability, I've already long ago written my own multi-user
persistent object store, and I think I'll
> live more than a bit longer if I never have to think about porting it to
Windows!
>
Well there you go, my point exactly!
I would suggest that your programming ability was significantly enhanced
simply because you DID write your own "multi-user persistent object store".
I came into this posting by making a point to a (possibly new) programmer
that he/she should consider rolling their own database routines so they
could at least be aware of what goes on at the grass-roots level and the
power such an approach can deliver. Without this knowledge I believe we are
heading down a dangerous path where we limit our ability only to tools made
available from the likes of MS and others who will manipulate us to suit
their own commercial goals.
> Anyway, if you're so against "burdening" your applications with
"additional
> baggage and performance degrading add-ins", WTF are you doing using Visual
> Basic? "Real Programmers" use assembly language, since even C burdens
one's
> applications with too much "additional baggage and performance degrading
> add-ins" like printf()! Microsoft BASIC -- what are you, some sort of
wuss?
>
I guess we all have a limit to just how far we will go. 100% assembly code
programming isn't practical, nor is it required in today's operating system
environments. This however doesn't mean we only use tools written for us by
outside sources thus positioning ourselves even further beyond comprehension
of the job at hand.
If my local mechanic could only work on my vehicle by connecting "objects"
like exhaust manifolds, alternators and fuel lines I believe I would seek
out a mechanic who actually knew how to "assemble" my engine using pistons,
con-rods, bearings and alike - wouldn't you? But this doesn't mean I would
expect him to manufacture the pistons and other parts in his own workshop.
As of the 27th I will be holidaying in remote areas of Australia for around
4 -5 weeks so my Internet access will be very limited. I trust this thread
continues as I believe everyone has contributed some interesting and valid
points.
Cheers for now,
Shane
Joe "Nuke Me Xemu" Foster
> "Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
> news:tte12rk...@corp.supernews.com...
> I can confidently state that my database handler code would be no more
> susceptible to failure than any of the commercially available engines. This
> can be stated because my code has remained fundamentally the same for many
> years and is used in many real-world applications daily. Granted, my code
> hasn't been tested for a period "which amounts to sagans and sagans of hours
> of real-world testing" however there does come a time when you can feel
> confident that your code is as error free as is possible notwithstanding the
> limitations of the compiler and operating system.
Has Windows 2000's "oplocks" impacted your code in any way?
http://support.microsoft.com/support/kb/articles/Q300/2/16.ASP
> I would suggest that your programming ability was significantly enhanced
> simply because you DID write your own "multi-user persistent object store".
It certainly "significantly enhanced" my computing paranoia, ie, "What
you don't know WILL hurt you!"
> I came into this posting by making a point to a (possibly new) programmer
> that he/she should consider rolling their own database routines so they
> could at least be aware of what goes on at the grass-roots level and the
> power such an approach can deliver. Without this knowledge I believe we are
> heading down a dangerous path where we limit our ability only to tools made
> available from the likes of MS and others who will manipulate us to suit
> their own commercial goals.
Actually, I hear MIT, and possibly other universities, are in the process
of putting their entire CS curriculum online, for free:
There may even be freely available example multiuser-capable data-stores
written in some version of Basic, just a Google search away. Studying or
debugging one of those ought to be very educational.