Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Portable code - relative/explicit file names

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Portable code - relative/explicit file names

    I am not an Alpha 5 developer, and am posting this on behalf of a colleague...

    Are there guidelines as to 'best practices' in making code portable between different deployment scenarios?

    My colleague has hust hit a problem in a network environment whereby client PCs receive error messages when system cards are run - the problem would appear to be where the card explicitly states the full path to the bdf file. In this particular case the data resides on the server in C:\appName\. C:\appName\ has then been set up as a share as S: on the client pc's. It would then appear that when the system card runs and tries to use the explicit C:\appName\...dbf table, the table cannot be found as C:\appName does not exist on the client.

    Also my colleage has also 'split' the data and created a subdirectory under appName called 'accounts' where he has put all the accounts related tables. The problem appears to be here, that on the 'system cards', you can either specify the explicit full path of a table OR the tableName.dbf. How then, in this case where accounts/tableName.dbf needs to be specified, can I do that? What a relative path list that is specified in the card, the Save throws an error. So, in this case it seems the only option is to enter a full path - but that then causes the issue above re portability.


    Obviously something is being missed this end that's causing the confusion.


    Sorry if the explanation is a bit garbled - I'm not too sure of the Alpha 5 terminology etc.

    #2
    Re: Portable code - relative/explicit file names

    my opinions.

    1. all data should be in one folder

    2. mostly where alpha inserts a hard path, you can take the path part out and leave the table or name and it works.

    3. Put no hard paths in unless absolutely necessary and if necessary, make sure what you pathed is where it needs to be.

    there are other ways and sure you will hear from others. I have to go to a meeting now.
    Dave Mason
    [email protected]
    Skype is dave.mason46

    Comment


      #3
      Re: Portable code - relative/explicit file names

      Originally posted by SteveT View Post
      I am not an Alpha 5 developer, and am posting this on behalf of a colleague...

      Are there guidelines as to 'best practices' in making code portable between different deployment scenarios?

      My colleague has hust hit a problem in a network environment whereby client PCs receive error messages when system cards are run - the problem would appear to be where the card explicitly states the full path to the bdf file. In this particular case the data resides on the server in C:\appName\. C:\appName\ has then been set up as a share as S: on the client pc's. It would then appear that when the system card runs and tries to use the explicit C:\appName\...dbf table, the table cannot be found as C:\appName does not exist on the client.

      Also my colleage has also 'split' the data and created a subdirectory under appName called 'accounts' where he has put all the accounts related tables. The problem appears to be here, that on the 'system cards', you can either specify the explicit full path of a table OR the tableName.dbf. How then, in this case where accounts/tableName.dbf needs to be specified, can I do that? What a relative path list that is specified in the card, the Save throws an error. So, in this case it seems the only option is to enter a full path - but that then causes the issue above re portability.


      Obviously something is being missed this end that's causing the confusion.


      Sorry if the explanation is a bit garbled - I'm not too sure of the Alpha 5 terminology etc.
      http://support.alphasoftware.com/alp...EXE_PATH().htm

      http://support.alphasoftware.com/alp...TER_PATH().htm

      http://support.alphasoftware.com/alp...GET_PATH().htm

      http://support.alphasoftware.com/alp...ATE_PATH().htm

      http://support.alphasoftware.com/alp...RED_PATH().htm

      I linked several xbasic functions that will return paths. Depending upon what it is you are wanting you can use these as the starting point for creating the path via xbasic.

      A general rule of thumb that I follow is that everyone connects to the database in the same way. If some of the users connect to the database via the S:\ drive mapping then all of the users need to connect via the same way. If the database is hosted on the C:\ drive for one machine you should go ahead and map the s:\ drive to point back to the C:\ drive. Then access the database via the S:\ drive. By following this guide line you can cheat and hardcode your paths into the scripts. Keep in mind cheaters usually get caught and being caught cheating can carry unforeseen costly penalties.

      In the long run it is easiest to have your paths built dynamically in the xbasic script using the above linked functions as a starting point.

      Example
      Code:
      A5.GET_PATH()+chr(92)+"accounts" +chr(92) + "table_name.dbf"
      Andrew

      Comment


        #4
        Re: Portable code - relative/explicit file names

        My colleague has hust hit a problem in a network environment whereby client PCs receive error messages when system cards are run - the problem would appear to be where the card explicitly states the full path
        Just a quick question...

        You said system CARDS. What version of the software is being run here?

        The CARD System was an old ver 1 method of creating an application. I still use it, but in ver 8, it is much different. In ver 1, there was an application instead of a "database", and a "database" was what ver 8 users call a "table".

        Those differences could influence the way that we respond to the questions.

        Tom

        Comment


          #5
          Re: Portable code - relative/explicit file names

          When connecting your application to the server(I hope you are using shadowed), it is somewhat better9my opinion) to use

          \\name of server\foldername\adbname(like sales.adb)
          if you are not shadowing, there are a whole lot of worms that are out of the can.

          More information is needed before anyone can give you a lot of help here. We are all guessing, alt least I am.

          terminology help

          adb file is your alpha database
          dbf is a table

          As tom said, cards are rarely used anymore and could disappear in a future version. It is best to get away from them asap if that is in fact what you are using.

          all you data should be accessible in your shadowed copy that would be available from the server. If you have bitmaps or other files that are not included in the shadow, you can specify those files to be included which would copy them over to the user machine or you can manually copy them over.

          As andrew said you can put in a path()(among others) statement or other instead of a hard coded path to retrieve the data.

          A little searching of the help files can be a blessing.
          Dave Mason
          [email protected]
          Skype is dave.mason46

          Comment


            #6
            Re: Portable code - relative/explicit file names

            All,
            Thanks for all the replies.

            The Alpha version being used is 7.
            What I mean by 'system card' is where you use a predefined process to perform an action such as an append or post.
            To me, a table is a collections of related rows (a row a set of related columns) and a database is a collection of related tables.

            The application is being accessed from two distinct 'routes' - ie from network attached PCs where they connect to the database via a network shared drive (ie S:\appName\....) and also directly from the server (where the connection is direct to the C:\appName\ drive). This is what first highlighted the issue - as a user running an 'append' card from the server worked fine, but the same card being run from the networked PCs failed as the append card had an explicit path to a table (the assumption then being that the append would be looking for the C:\appName\.... table specified in the card on the 'client' PC - where that directory/table never existed).
            To compound the problem - the application (for legacy reasons) has the database split in two directories - the main C:\appName\... location and also a subdirectory under that called Accounts. The Accounts sub folder then carries (as you may have guessed) accounting related tables. The secondary issue then was that in the 'cards' - the table definitions didn't allow for relative paths. For example if my main table was C:\appName\table1.dbf and I want to append from table2.dbf that happens to be in accounts, I cannot specify just Accounts\table2.dbf - I can either specify table2.dbf (ie without any path at all and Alpha appears to assume the path of the table being appended to) or I can specify the full path to the table (ie C:\appName\Accounts\table2.dbf) - which then gives me the catch 22 with client-server type access.

            Does that make it any clearer? (Like mud eh?)

            Comment


              #7
              Re: Portable code - relative/explicit file names

              Your term, "card" is called an "operation". it would help you here to use that.

              The append can be turned into a script, which is another matter.

              before the append, a little code can get you a hard path to that table(s) by using the functions provided above into a variable. In the append you can use that variable(I think) along with that table name and it should work. i have not tried that, but see no reason it cannot work. if it doesn't, you could convert the operation to a script and do it there. a script will work faster than an operation in almost all cases and a function will go even faster.

              example append from one of mine:
              Code:
              DIM Append as P
              ' now the "inv"could be doe with  my already defined variable "cpath2" that has "c:\ups55\folder\" in it to
              'a_tbl = table.open(alltrim(var->cpath2)+"inv")
              
              'below is real like i use it
              
              a_tbl = table.open("inv")
              append.t_db = "inventor"
              'ON ERROR GOTO ERROR24092007170516515
              
              
              append.m_key = "Stock"
              append.t_key = "Stock"
              append.m_filter = ""
              append.t_filter = ".not.isblank(\"stock\").and..not.isblank(\"pdate\").and..not.isblank(\"make\").and..not.isblank(\"vin\").and.len(stock)>=4.and.date()-pdate<365"
              append.type = "Unique only"
              append.m_count = 2
              append.m_field1 = "Lot"
              append.m_exp1 = "Var->lot"
              append.t_count = 0
              
              a_tbl.append()
              
              a_tbl.close()
              i see there was a reason the folders were split and suggest it be rethought. Just because tables share the same folder does not make them any more/less usable or in any way shared by the others, but can drastically help processes as you can see now.
              Last edited by DaveM; 02-02-2008, 10:08 AM.
              Dave Mason
              [email protected]
              Skype is dave.mason46

              Comment

              Working...
              X