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 <[email protected]> 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" <[email protected]> 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 > [email protected] > > 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" <[email protected]> wrote: > 2009/11/11 Adam <[email protected]> > > > > 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 > [email protected] > > 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 <[email protected]> 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.
