Professional Web Applications Themes

Question coding a database app for Mac OSX - Mac Programming

Hey, there, folks. I'm currently looking to get back into coding (haven't done it in about ten years, since Pascal -yikes!), and want to create a contact management database program for Mac OSX. This is a program for a salesperson to keep track of contact addresses & other contact info, histories, business expenses...your standard individual user database (doesn't need workgroup networking functions...although we may want to work in a Palm OS export function, eventually).... Also, for now, I'm only interested in Mac...but will probably want to bring it to Windows fairly soon, as well...with as much ease and keeping as ...

  1. #1

    Default Question re: coding a database app for Mac OSX

    Hey, there, folks. I'm currently looking to get back into coding
    (haven't done it in about ten years, since Pascal -yikes!), and want
    to create a contact management database program for Mac OSX.

    This is a program for a salesperson to keep track of contact addresses
    & other contact info, histories, business expenses...your standard
    individual user database (doesn't need workgroup networking
    functions...although we may want to work in a Palm OS export function,
    eventually)....

    Also, for now, I'm only interested in Mac...but will probably want to
    bring it to Windows fairly soon, as well...with as much ease and
    keeping as much functionality as possible.

    So the first question is, before I just dive into some random language
    and find it's not the right one to be messing with, what should I code
    this program in? I know a bit of SQL, so I could perhaps create the
    database itself in SQL...but how to code the GUI? Or would it be
    better to find a language that has its own database functionality, and
    work without SQL?

    Do I look at C? C++? Java? Apple's new X-Code? PHP, PERL? Python? The
    possibilities are staggering, and like I said, I'm just getting back
    into this. There's no good description out there of what each
    language's capabilities are, within the Apple & Windows frameworks.
    <sigh>...things were a lot simpler back in DOS 6.22.

    As for the cross-platform thing, should I go ahead and find a
    cross-platform language? That would seem to make more sense than
    starting from scratch when I move it to Windows, wouldn't it?

    Any help would be very much appreciated. It's a bit confusing, trying
    to sort all this out.

    Thanks,

    Kipp
    Kipp Chambers Guest

  2. #2

    Default Re: Question re: coding a database app for Mac OSX

    In article <7cceffee.0308091743.7a188aceposting.google.com >,
    [email]petrelactor[/email] (Kipp Chambers) wrote:
    > Hey, there, folks. I'm currently looking to get back into coding
    > (haven't done it in about ten years, since Pascal -yikes!), and want
    > to create a contact management database program for Mac OSX.
    >
    > This is a program for a salesperson to keep track of contact addresses
    > & other contact info, histories, business expenses...your standard
    > individual user database (doesn't need workgroup networking
    > functions...although we may want to work in a Palm OS export function,
    > eventually)....
    There are a number of cross-platform frameworks out there, and there is
    also Java. Is cross-platform more important than having a comfortable
    application on the Mac? Would it be better to write it fast, to have it
    written on one platform, then look at rewriting a working system into a
    portable one? (I think so. My experience has been that trying to be
    cross-platform from the start over-constrains the problem, so that that
    program doesn't get finished.)

    Take a look at <http://wxWindows.org/> a free, open source, cross
    platform framework for MS-Windows, Mac, and Linux. It includes classes
    that support ODBC on Windows, and SQLite under Mac and Windows. Both are
    wrappers around SQL.

    You might try searching in <http://www.google.com/> and in
    <http://groups.google.com/> for wxWindows and mySQL, to see if anyone
    can give you guidance on supporting both.

    I myself use PowerPlant, and am in the process of switching to the new
    powerplant for OS X, because it has so many recent good ideas in its
    usage of C++, and its mapping to OS X, but I don't usually interface to
    SQL databases.
    David Phillip Oster Guest

  3. #3

    Default Re: Question re: coding a database app for Mac OSX

    In article <oster-3DDEA4.20302409082003news.sf.sbcglobal.net>, David
    Phillip Oster <osterieee.org> wrote:
    > There are a number of cross-platform frameworks out there, and there is
    > also Java. Is cross-platform more important than having a comfortable
    > application on the Mac? Would it be better to write it fast, to have it
    > written on one platform, then look at rewriting a working system into a
    > portable one? (I think so. My experience has been that trying to be
    > cross-platform from the start over-constrains the problem, so that that
    > program doesn't get finished.)
    Depending on your needs, you might be able to use REALbasic, which is
    cross-platform.

    --
    David Dunham A Sharp [email]davidSPAM_B_GONE.a-sharp.com[/email]
    [url]http://www.pensee.com/dunham/[/url]
    "I say we should listen to the customers and give them what they want."
    "What they want is better products for free." --Scott Adams
    David Dunham Guest

  4. #4

    Default Re: Question re: coding a database app for Mac OSX

    Much thanks for the advice, Mikey, David & David.

    The problem I keep having is knowing what each language will allow me
    to do. If I want to, say, provide a way to track meetings (like a
    calendar function) and link them to contacts, as well as eventually
    find a way to export contacts to Palm/PocketPC and export expense
    items to Quicken, will Java or RealBASIC be able to support that
    functionality?

    Or adding a quick-entry side-program, for jotting random notes or
    expenses down, that will streamline the process of transferring them
    in later?

    I guess the overall question is, since I'm starting from scratch here
    (I don't think that Pascal is going to do me much good, right? :),
    what will give me the most functionality with the shortest learning
    curve? (I know, I know, it's the wonder-question...but there's just
    too much to look into, and I don't want to get in over my head only to
    find that the language I've been learning is not going to do what I
    need it to).

    Anyone know of someplace that lists out a good number of programming
    languages, their advantages, and their disadvantages? That's what I
    really need to find out, I suppose. The database I can build
    myself...it's mostly a matter of conceptualizing the entities, etc.
    But what are the plus's and minus's of using the different languages?

    Thanks again, y'all. You have no idea how much I appreciate it.

    Kipp
    Kipp Chambers Guest

  5. #5

    Default Re: Question re: coding a database app for Mac OSX

    [email]petrelactor[/email] (Kipp Chambers) wrote in message news:<7cceffee.0308091743.7a188aceposting.google. com>...
    > this program in? I know a bit of SQL, so I could perhaps create the
    > database itself in SQL...but how to code the GUI? Or would it be
    > better to find a language that has its own database functionality, and
    > work without SQL?
    Just to be nitpicky (though hopefully it will help in a small way) you
    can not create a database in SQL. SQL is a language for talking to a
    database. You have to have some database to talk to that understands
    SQL.

    Robert
    Robert Smith Guest

  6. #6

    Default Re: Question re: coding a database app for Mac OSX

    "Robert Smith" <rsmithncbi.nlm.nih.gov> wrote in message
    news:af76600b.0308110456.6e0b728aposting.google.c om...
    > [email]petrelactor[/email] (Kipp Chambers) wrote in message
    news:<7cceffee.0308091743.7a188aceposting.google. com>...
    > > this program in? I know a bit of SQL, so I could perhaps create the
    > > database itself in SQL...but how to code the GUI? Or would it be
    > > better to find a language that has its own database functionality, and
    > > work without SQL?
    >
    > Just to be nitpicky (though hopefully it will help in a small way) you
    > can not create a database in SQL. SQL is a language for talking to a
    > database. You have to have some database to talk to that understands
    > SQL.
    To be equally nitpicky, SQL is a language for talking to a dbms and not to a
    database, and the original poster was correct to say he was creating a
    database using SQL--he merely assumed he would use SQL to instruct the dbms
    to create the database.


    Bob Badour Guest

  7. #7

    Default Re: Question re: coding a database app for Mac OSX

    > > this program in? I know a bit of SQL, so I could perhaps create the
    > > database itself in SQL...but how to code the GUI? Or would it be
    > > better to find a language that has its own database functionality, and
    > > work without SQL?
    >
    > Just to be nitpicky (though hopefully it will help in a small way) you
    > can not create a database in SQL. SQL is a language for talking to a
    > database. You have to have some database to talk to that understands
    > SQL.
    >
    > Robert
    Gotcha, Robert. I was typing fast, not taking the time to qualify each
    idea/phrase. That being said, I don't suppose you have any suggestions
    for the problem/question at hand? (I can obviously use all the help I
    can get here).

    I guess the choices pretty much come down to Java, REALBasic, and C++
    (via Codewarrior/PowerPlant). Which would one of you prefer to use to
    create a database app?

    Much thanks,

    Kipp
    Kipp Chambers Guest

  8. #8

    Default Re: Question re: coding a database app for Mac OSX

    Kipp

    One of the single biggest deciding factors is how you want to be able to
    deploy your applications. Do you want
    a) a doent that can be copied around
    b) a doent that can be opened by multiple users simultaneously
    c) a separate server for which you write clients
    d) all of the above

    A lot of SQL-oriented solutions require a client-server database.

    I believe Valentina provides an embeddable engine but I'm not sure.

    I picked Faircom's c-tree engine over 11 years ago as a robust
    cross-platform engine and have never regretted it.

    OOFILE is a database framework with which you can get started for free
    and pay for a commercial backend (using c-tree) later if you need larger
    databses. It also has a full report writer, which is mostly lacking with
    other solutions.

    It requires you to work in c++ (a very minimal level) and has GUI
    bindings for PowerPlant and MFC currently shipping, more Mac ones coming
    (but I'm not promising dates until they are ready).

    I've had a lot of recent experience at using a c++ engine underneath
    GUI's written for specific platforms - Cocoa and MFC on Windows and
    PocketPC (and experimenting with POL on Palm, included with CodeWarrior9
    for Palm).

    Cocoa GUI's on top of C++ engines are easy to write.

    I have avoided Carbon-based GUI's on OS/X until now because of concerns
    about stability and bugs - some Cocoa behaviours are still nicer (eg:
    file open dialogs).

    I'm looking forward to PowerPlantX.

    You need to also seriously consider the Classic Mac market for which I'd
    recommend PowerPlant or RealBASIC. There are going to be a lot of cheap
    Macs around for many years that can't run OS/X, especially laptops.

    --
    Andy Dent BSc MACS AACM [url]http://www.oofile.com.au/[/url]
    OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
    PP2MFC - PowerPlant->MFC portability
    Andy Dent Guest

  9. #9

    Default Re: Question re: coding a database app for Mac OSX


    Or you could use something like 4th Dimension, of course. It depends
    how much of the work you want to do for yourself.

    Jeremy

    In article <bhaa89$v9u8s$2ID-2640.news.uni-berlin.de>, Thomas
    Engelmeier <jun03_nospamengelmeier.com> wrote:
    > [email]petrelactor[/email] (Kipp Chambers) wrote:
    >
    > > I guess the choices pretty much come down to Java, REALBasic, and C++
    > > (via Codewarrior/PowerPlant). Which would one of you prefer to use to
    > > create a database app?
    >
    > Given you have no much coding experience and want a solution fast:
    > RealBasic. The Pro version has AFAIR some database capabilities.
    >
    > Writing a _good_ Java UI on MacOS requires a bunch of tweaking.
    >
    > C / C++ has a long learning curve, you should start learning the
    > language in little steps.
    >
    > Regards,
    > Tom_E
    Jeremy Roussak Guest

  10. #10

    Default Re: Question re: coding a database app for Mac OSX

    [email]petrelactor[/email] (Kipp Chambers) wrote in message news:<7cceffee.0308102147.687c1c50posting.google. com>...
    > The problem I keep having is knowing what each language will allow me
    > to do. If I want to, say, provide a way to track meetings (like a
    > calendar function) and link them to contacts, as well as eventually
    > find a way to export contacts to Palm/PocketPC and export expense
    > items to Quicken, will Java or RealBASIC be able to support that
    > functionality?
    >
    > Or adding a quick-entry side-program, for jotting random notes or
    > expenses down, that will streamline the process of transferring them
    > in later?
    >
    > I guess the overall question is, since I'm starting from scratch here
    > (I don't think that Pascal is going to do me much good, right? :),
    > what will give me the most functionality with the shortest learning
    > curve?
    The problem is that your requirements are contradictory, and no one
    language fills them all. Even within a single functional system, it's
    common to see different languages used in different places. A
    reasonbly sophisticated Intranet, for example, might have a
    presentation tier made of HTML, JavaScript, and occasionally some
    Java, a business logic tier made of Perl or PHP or both, a server tier
    made of Java, and a persistence tier made of "Bob" knows what, because
    you bought it from Oracle.

    Here, what you have is not an enterprise system but one that's nearly
    as complex. You want to 1) put together user interfaces easily, 2)
    support some sort of database, as yet unspecified, and 3) provide
    interconnection, such as via a Palm conduit.

    A language that is fun to use and gives you a quick emotional bang
    for the investment of time is not going to be the same thing as one
    that you're going to use when you need to get close to the metal and
    write a Palm conduit. You're going to have to give something up
    or at least defer it until later, when you're back in the swing of things.

    Here's an offer. Pick two, but only two, from the following list of
    desirables, and I'll make suggestions:

    1) Power and control
    2) The ability to build applications easily
    3) Compatibility with platforms other than OS X
    Eric Pepke Guest

  11. #11

    Default Re: Question re: coding a database app for Mac OSX

    In article <7cceffee.0308091743.7a188aceposting.google.com >, Kipp
    Chambers <petrelactor> wrote:
    > Hey, there, folks. I'm currently looking to get back into coding
    > (haven't done it in about ten years, since Pascal -yikes!), and want
    > to create a contact management database program for Mac OSX.
    >
    > This is a program for a salesperson to keep track of contact addresses
    > & other contact info, histories, business expenses...your standard
    > individual user database (doesn't need workgroup networking
    > functions...although we may want to work in a Palm OS export function,
    > eventually)....
    >
    > Also, for now, I'm only interested in Mac...but will probably want to
    > bring it to Windows fairly soon, as well...with as much ease and
    > keeping as much functionality as possible.
    >
    > So the first question is, before I just dive into some random language
    > and find it's not the right one to be messing with, what should I code
    > this program in? I know a bit of SQL, so I could perhaps create the
    > database itself in SQL...but how to code the GUI? Or would it be
    > better to find a language that has its own database functionality, and
    > work without SQL?

    You could, if you didn't want to go to the trouble of writing the GUI,
    make this project Web based. It would certainly satisfy the platform
    indepence aspect of the project.

    A very fast solution would be to build a mod_perl/Apache server on the
    macintosh and code the Database interface in a Web-friendly langauge
    such as Perl or PHP. For the RDBMS, you have a few choices, but MySQL
    is a easily deployable solution. I've built two client management
    systems such as this that work well and were low cost to develop and
    deploy.

    It makes for a decently scalable solution, as you could port the code
    to any server (although building mod_perl in the Windows World is no
    picnic) and even change the backend with out too much fuss.
    >
    > Do I look at C? C++? Java? Apple's new X-Code? PHP, PERL? Python? The
    > possibilities are staggering, and like I said, I'm just getting back
    > into this. There's no good description out there of what each
    > language's capabilities are, within the Apple & Windows frameworks.
    > <sigh>...things were a lot simpler back in DOS 6.22.
    Best of both world with OSX. You have Frameworks, but if you long for
    the good old days of the DOS window, you have ther terminal, and the
    familiar shell scripting tools of the UNIX world.
    >
    > As for the cross-platform thing, should I go ahead and find a
    > cross-platform language? That would seem to make more sense than
    > starting from scratch when I move it to Windows, wouldn't it
    Moving it to window doesn't make any sense, but it's your project.

    --
    cp
    cp Guest

  12. #12

    Default Re: Question re: coding a database app for Mac OSX

    > > The problem I keep having is knowing what each language will allow me
    > > to do. If I want to, say, provide a way to track meetings (like a
    > > calendar function) and link them to contacts, as well as eventually
    > > find a way to export contacts to Palm/PocketPC and export expense
    > > items to Quicken, will Java or RealBASIC be able to support that
    > > functionality?
    > >
    > > Or adding a quick-entry side-program, for jotting random notes or
    > > expenses down, that will streamline the process of transferring them
    > > in later?
    > >
    > > I guess the overall question is, since I'm starting from scratch here
    > > (I don't think that Pascal is going to do me much good, right? :),
    > > what will give me the most functionality with the shortest learning
    > > curve?
    >
    > The problem is that your requirements are contradictory, and no one
    > language fills them all. Even within a single functional system, it's
    > common to see different languages used in different places. A
    > reasonbly sophisticated Intranet, for example, might have a
    > presentation tier made of HTML, JavaScript, and occasionally some
    > Java, a business logic tier made of Perl or PHP or both, a server tier
    > made of Java, and a persistence tier made of "Bob" knows what, because
    > you bought it from Oracle.
    >
    > Here, what you have is not an enterprise system but one that's nearly
    > as complex. You want to 1) put together user interfaces easily, 2)
    > support some sort of database, as yet unspecified, and 3) provide
    > interconnection, such as via a Palm conduit.
    >
    > A language that is fun to use and gives you a quick emotional bang
    > for the investment of time is not going to be the same thing as one
    > that you're going to use when you need to get close to the metal and
    > write a Palm conduit. You're going to have to give something up
    > or at least defer it until later, when you're back in the swing of things.
    >
    > Here's an offer. Pick two, but only two, from the following list of
    > desirables, and I'll make suggestions:
    >
    > 1) Power and control
    > 2) The ability to build applications easily
    > 3) Compatibility with platforms other than OS X

    Hey, Eric. Thanks for the response.

    First off, I know that adding the Palm conduit, etc., will almost
    inevitably lead to more languages. I'm cool with that. That feature is
    an add-on from my 'wish-list' - I'll get to it in later stages of
    development. Right now, I'm just concerned with the app itself...how
    to perform the simple functions of entering data, manipulating data,
    performing queries, displaying the calendar, etc, and making them look
    user-friendly & spiffy graphically.

    You're right - it's definitely not an enterprise system. Heck, we're
    not even really talking client/server. It has no reason to be shared.
    This is for an individual, someone who's self-employed, to keep track
    of their schedule, as well as contacts, meetings, records of what went
    on at the meetings, and details of completed sales...all on their
    home-office-desktop-PC or PowerBook G4. Think of it as similar to
    Goldwave or ACT!, but for a very specific job market. Individual use.
    A personal database.

    That being said, I'll take you up on that offer.

    Let's definitely go with Option 3...and also Option 1. It needs to be
    interchangeable because the mac market is too small for this specific
    niche (it's just what I use). I suppose we'll go with power and
    control, because I've never been one to sacrifice quality for the easy
    way out. By "power and control" I simply mean speed of access time and
    ability to tell it to do "lots of cool stuff."

    At the moment, I'm thinking of using Codewarrior and coding in C++ for
    the base of the app's code. Unless you give me a good reason to turn
    in a completely opposite direction.

    Much thanks for weighing in with your thoughts.

    Kipp
    Kipp Chambers Guest

  13. #13

    Default Re: Question re: coding a database app for Mac OSX

    "Fetch, Rover, Fetch" <Fun_FurKaNine_University.edu> wrote in message news:<ABicnYDE2uAgiKGiU-KYvAbritsys.net>...
    > try 4th dimension
    >
    > [url]www.4D.com[/url]
    >

    I've checked out their site...looks like a decent environment for
    development. (Beats the heck out of Filemaker, that's for sure...and
    it's customizable, so it won't have '4d' stamped all over my app).

    But the question comes in: will it allow me to eventually add things
    like Palm Conduits (actually, I'll want to code a Palm version of the
    whole app, since the Palm address book is insufficient at listing
    histories, etc)...and then there's the cost issue. I can see spending
    $800 for a program to code something, but laying out $2500 for
    licensing, though not too bad, is still a pretty chunk of change at
    the moment.

    If it would do what I needed it to do, it becomes a question of the
    easy, expensive way (using the 4d development environment) versus the
    less expensive, more time-consuming way (developing the app myself).

    How about it: anyone have any experience, good or bad, developing a
    standalone database app with 4d?
    Kipp Chambers Guest

  14. #14

    Default Re: Question re: coding a database app for Mac OSX

    In article <7cceffee.0308192200.3e17e4f6posting.google.com >,
    [email]petrelactor[/email] (Kipp Chambers) wrote:
    > > 1) Power and control
    > > 3) Compatibility with platforms other than OS X
    > At the moment, I'm thinking of using Codewarrior and coding in C++ for
    > the base of the app's code.
    OOFILE and AppMaker (says the vendor).

    You get a database language (compilable c++) designed from years of 4D
    frustration. (I went back to consult on a site for which I wrote a 4D
    enterprise-wide info system 11 years ago recently and the latest 4D
    *still* doesn't fix some of the lacks I was frustrated about in the
    early 90's).

    Ability to exchange data in dBase format.

    Cross-platform report-writer (the oft-neglected side of database
    programming).

    Engine scalable to client-server and big numbers of records - my ISP use
    it for tracking all IP packets, monthly databases in the hundreds of
    millions of records, queried online by their user statistics pages. I
    wouldn't even dream of putting a million records in 4D (OK, maybe the
    engine is more robust nowadays) but the Faircom c-tree engine in our
    professional version is industrial strength. BTW they are a major MySQL
    developer but use OOFILE in preference for this size of data management!

    You can start with OOFILE for free - the only retail components are
    currently the database backends.

    The main catch, if you're planning on targetting OS/X Cocoa apps, is
    that we haven't finished a Cocoa integration of some features. That's
    coming (and as it is going to be part of the open source version, along
    with the current MFC and PowerPlant GUI integration, volunteers to help
    would be appreciated - I'm very busy on other projects and the guy lined
    up to do it goes in for an unexpected bypass operation on Friday).

    --
    Andy Dent BSc MACS AACM
    OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
    PP2MFC - PowerPlant->MFC portability
    [url]http://www.oofile.com.au/[/url]
    Andy Dent Guest

  15. #15

    Default Re: Question re: coding a database app for Mac OSX

    [email]petrelactor[/email] (Kipp Chambers) wrote in message news:<7cceffee.0308192200.3e17e4f6posting.google. com>...
    > Let's definitely go with Option 3...and also Option 1. It needs to be
    > interchangeable because the mac market is too small for this specific
    > niche (it's just what I use). I suppose we'll go with power and
    > control, because I've never been one to sacrifice quality for the easy
    > way out. By "power and control" I simply mean speed of access time and
    > ability to tell it to do "lots of cool stuff."
    >
    > At the moment, I'm thinking of using Codewarrior and coding in C++ for
    > the base of the app's code. Unless you give me a good reason to turn
    > in a completely opposite direction.
    For sheer power, CodeWarrior is hard to beat. Also, if you decide to get
    into Palm programming and you already have the Mac version of CodeWarrior
    with the 68K compiler, you can download the Palm SDK and all the appropriate
    CodeWarrior wizards for free. (At least you could with my older version, but
    I haven't upgraded that recently.) The Mac CodeWarrior also allows cross-
    compilation for Win32, which you can run under a Mac windows emulator
    for convenience. I doubt that the speed differences are going to be significant
    for your application.

    One big problem is that the user interface code for the Mac application is going
    to be totally different from the WIN32 version. So, even though this isn't an
    enterprise application, you're going to have to do some good enterprise-level
    programming, including having a separate interface layer. This is not so easy
    to do and requires some forethought.

    Another is C++ itself. C++ is a pseudo-O-O system essentially grafted onto
    C-like syntax. It's a behemoth. It is possible, if you already know what you're
    doing, to do fairly decent object code in C++. However, it's also possible
    to write complete crap code. Since you're learning, I'd suggest a conservative
    approach: concentrate on the features that are common to C++ and C.

    I'd also suggest something that you might find rather odd. Write your
    interface code in Objective C for Cocoa. Objective C is a superset of C.
    But don't write anything else in Objective C. The reason I suggest this is
    that the fact that Objective C is so different from C++ that it will force
    you to think about how to do the interface between the interface layer
    and the business/persistence layers.

    At first, you might think Carbon in C++ is a better choice, since its
    more similar to the Win32 API. However, this kind of similarity is more
    likely to cause confusion than to make it easy to convert. I'd really
    suggest just planning to have completely separate code bases for
    the interfaces.

    By now, you should have noted that the interface is going to be
    the trickiest thing. Something like RealBasic makes this a lot
    easier to do; however, I'm not sure that RealBasic gives you enough
    power. However, I haven't made anything other than toy applications
    in RealBasis; they probably have a plug-in mechanism.

    By default, C is the standard. If there's a plug-in mechanism or a
    library that you want to use, dollars to doughnuts it's going to be
    accessible via C.
    Eric Pepke Guest

Similar Threads

  1. General Database question
    By mrjoy82 in forum Macromedia Flex General Discussion
    Replies: 1
    Last Post: May 2nd, 03:31 AM
  2. database design and asp question
    By Michael in forum Dreamweaver AppDev
    Replies: 2
    Last Post: June 27th, 09:23 AM
  3. Database question
    By Hardik Doshi in forum PHP Development
    Replies: 8
    Last Post: March 22nd, 04:37 PM
  4. Database and asp question
    By William E Hatto in forum ASP Database
    Replies: 12
    Last Post: February 3rd, 01:09 PM
  5. Coding Question
    By Aaron Axelsen in forum PHP Development
    Replies: 1
    Last Post: July 20th, 12:51 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139