Okay looks like i used the wrong terms to describe what i meant by
Flat File DB (upfront - my apologies!).
A little more on the project, its a Rate Simulation program where it
takes shipment weights and compares against rate sheets that the user
saves (so they are a production sheet that other users would have to
concern themselves with primarily) and gets the cost of that shipment
using sheet a, or sheet b....etc
On Nov 11, 10:38 pm, Cerebrus <zorg...@sify.com> wrote:
> Questions:
> 1. Define what you imply by "flat file". Also define what you mean by
> the (oxymoronic !) term "flat file database".
I mean a portable-ish Database File, something along the lines of
embedded databases (like SQLite), i group MS Access in the same group
simply because (and i am testing my knowledge here) it can for the
most part not rely on anything but the JET Engine for access and
SQLite takes it that much further and it's access engine/library is
integrated with the application its designed with.
> 2. Is your "flat file" actually an MS Excel spreadsheet (.xls) ? Or
> you want to import data from an .xls into a flat file ?
Most of this question goes away i think now that i found my
terminology misstep, The imported data is coming from an XLS into the
embeded database.
> 3. Why can't the import be done directly from MS Excel ? Why does MS
> Access have to come into the picture at all ?
The access has to come into play (from my project lead's perspective)
is so we can edit the imported data after the fact without writing in
extra code
> Haven't had my morning coffee yet, so apologies if these are dumb
> questions! :-)
On Nov 11, 10:44 pm, "Charles A. Lopez" <charlesalo
...@gmail.com>
wrote:
> What is an SOP?
Standard Operating Procedure, required set of instructions/rules users
must follow to accomplish a task.
i.e. user received shipping appointment email, they must collect a
predefined set of caller details and record this in the appropriate
scheduling application.
> --
> Charles A. Lopez
> charlesalo...@gmail.com
> Registered Microsoft Partner
> New York City, NY
> I'm running on Windows 7 Build 7100
> Quality Software Works
On Nov 11, 10:54 pm, "Charles A. Lopez" <charlesalo
...@gmail.com>
wrote:
> 2009/11/11 Adam <adam.cheese
...@gmail.com>
> Why are you manipulating the data with Access if you intend to "write a
> program"?
the program has already been written using an online method (i.e.
reads shipping data from existing shipments and an excel rate sheet
that user provides)
The new addition will allow the user to give an excel sheet full of
shipments (shipments we don't exist in the system so we can quote cost/
revenue appropriately)
and i am trying to minimize the impact of introducing the embeded
database for creating portability. (i hope that makes sense...:S)
> --
> Charles A. Lopez
> charlesalo...@gmail.com
> Registered Microsoft Partner
> New York City, NY
> I'm running on Windows 7 Build 7100
> Quality Software Works
On Nov 12, 3:42 am, Processor Devil <processor.de
...@gmail.com> wrote:
> flat file database can be:
> binary file where every columns is based on already defined length of
> characters (like sql), it means:
> name (10 chars), surname(10 chars), email(20 chars), etc.
> It can also be XML, unix database file (columns separated by commas, equal
> marks, etc)
> It can also be serialized class or such things...
> I have one question upon the OP:
> so you need to write program that can "login" even if offline. It means that
> every user will have his own database flat file OR his own copy of database
> flat file... This can destroy the data consistency and also easily allow
> someone to change data in the flat file and bypass security...
Because the data the user would have on their own db file doesn't
impact others, data consistency isn't a big concern (even though i
have brought it up in a project meeting, so it is something i have
thought about).
> I wonder if it wouldn't be better to have some sql server or some logon
> service on one computer of the network (eg on server) and all remaining
> computers would send their login credentials there (of course in encrypted
> form).
> Good hint is that passwords and such data should be hashed.
|
