Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.databases.paradox    |    To crash or not to crash, asks Borland    |    9,834 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 9,359 of 9,834    |
|    Michelle Burnore to Leslie Milburn    |
|    Re: Overview of Paradox database structu    |
|    01 Aug 08 21:29:49    |
      From: michelljb@aol.com              Leslie,              Initially, I had the same reaction as you.....Paradox system - OPal,       Forms - Data Models - Reports - Data structures that ALL are dependent       on, being converted to a "like" system in Access....big project. Even       if you are experienced in both, it's a project. But then when his       further posts were asking for basic database structure, I thought, well       maybe we are over-complicating this, and he just needs to know if       Paradox tables have compatible field types to Access, so when doing a       simple import, there would be no surprises. I know that importing a       Paradox table to Access is a no-brainer in most cases, but what if the       Paradox table has a field type that Access can't cope with? I was       looking at his questions in that vein.              I haven't seen anything in his posts that suggests system replacement,       so I didn't go there.              I found no fault with the tone of any of your post, Leslie. I can't       speak for Dominick, but I think at that point he was on a roll, and any       negativity would be treated like an attack.              Again, I'll say, I had and have, no problem with cautioning someone who       might really WANT a position with a client, but who may not be qualified       to hold it. However, he seemed to be getting that response in spades,       so it hardly was productive for me to do likewise.              I like to give people the benefit of the doubt. He asked how a Paradox       table is structured, and I gave him field types. Never said I was       giving the schematics to the universe, just giving him the basics. He       is probably vague about what he needs to know, because the client hasn't       given him enough information yet.                     Leslie Milburn wrote:ex       > Hi Michelle,       >       > I always understood the question to be basically about data migration but I       > can also see that based upon the phrasing used it was probably more,       > otherwise the OP would know to just open the tables directly in ACCESS and       > copy them over and then work fully within the environment he is comfortable       > with. Hence no issue in any case.       >       > BUT, in some projects that will not be enough. I have worked on projects       > especially older ones where data *not* being present meant something. In       > order to know under which scenarios data would not be present required       > access to the business rules. To read the business rules in P4W would       > require navigational knowledge in order to locate the code in the first       > place (Not usually centrally located in older apps), and then you would need       > to be fairly proficient in OPAL to then read the code etc.       >       > In other words there is a difference between transference of data and system       > replacement, just like there is a difference between a Business Analyst and       > a Systems Analyst, close but maybe not close enough.       >       > I should also point out that my tone was clear and concise and he can take       > it or leave it. BUT know this, a good interviewer cannot be fooled and it       > really is that simple. If the OP is comfortable with his approach then I for       > one do not care and I wish him well.       > Leslie.       >       >       > "Michelle Burnore" |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca