Alpha Video Training
Page 1 of 2 12 LastLast
Results 1 to 30 of 43

Thread: Table Open Table structure

  1. #1
    Member
    Real Name
    Dave Mac Callum
    Join Date
    Jan 2006
    Location
    Johannesburg. South Africa
    Posts
    383

    Default Table Open Table structure

    Hi There,

    If I define a variable 's_item' as "sop_items_pos_prep" and code Table.open(s_item) it works ok
    If I load the variable 's_item' with a field Table Child from a table 'params_tnm_b' it does not work although debug sees the same result. How do I get to load the table id I require to open, by plugging it into a variable so I can use the same code for opening many tables ?

    I assume the function Table.open requires an id within inverted commas to work

    Can anyone out there in the big wide world help me ?

    Attaching screen dumps

    Looking forward
    Attached Images Attached Images
    Dave Mac

    It's not so much what you don't know that gets you into trouble, but what you know for sure, that just ain't so. - Mark Twain.

  2. #2
    "Certified" Alphaholic
    Real Name
    Tom Cone Jr
    Join Date
    Apr 2000
    Location
    Florida
    Posts
    23,310

    Default Re: Table Open Table structure

    Screen dumps are not as useful as actual code.

    First thought here is that you're forgetting to trim the trailing blanks from the field value you retrieve from the table. If so, your variable contains:

    Code:
    "table_name                   "
    instead of what you want, namely

    Code:
    "table_name"

  3. #3
    "Certified" Alphaholic Mike Wilson's Avatar
    Real Name
    mike wilson
    Join Date
    Apr 2005
    Location
    Grand Rapids, Michigan
    Posts
    4,198

    Default Re: Table Open Table structure

    I agree with Tom. Just cut and past the code, instead of screenshots, so we can use it as a foundation to respond. Can't cut and paste your code from screen shots.
    The second line of the commented out table.open() (second pane) uses a variable "s_items_prep" that is nowhere to be found in the code other than there. It wouldn't work not dimmed and undeclared.
    Mike W
    __________________________
    "I rebel in at least small things to express to the world that I have not completely surrendered"

  4. #4
    "Certified" Alphaholic Stan Mathews's Avatar
    Real Name
    Stan Mathews
    Join Date
    Apr 2000
    Location
    Bowling Green, KY
    Posts
    25,119

    Default Re: Table Open Table structure

    Another thought to consider. You don't specify whether this is a standalone or networked app.

    the .pack() method requires exclusive use of the table to perform its duties. Whenever you work out the correct .open() you should include the FILE_RX_EXCLUSIVE parameter and you probably want to throw in a bit of checking to see if it is possible to obtain the table parameter in exclusive mode.

    itmtest = table.in_use("your_table_name")
    if itmtest
    'in use, can't pack
    'warn the user
    else
    ' pack code here, etc
    end if

  5. #5
    Member
    Real Name
    Dave Mac Callum
    Join Date
    Jan 2006
    Location
    Johannesburg. South Africa
    Posts
    383

    Default Re: Table Open Table structure

    Hi Guys,

    Thanks for your prompt response.

    Trim hey, you were right Tom. If I had known that it would have trimmed a few frustrating hours off yesterday. Maybe I should learn to call for help sooner in these cases.

    Apologies for not giving you the complete story. Mike, I will see if i can cut and paste code to you...

    Sorry, not able to see how I can select where to paste my code to you - can you advise (one of the above icons? )

    Also tried to copy my db 'Focus_Universe' to a truncated version of a db 'Mess_board' to attach to you - where I have a few queries - got as far as not being able to duplicate all my Global variables that need to be initialized in Autoexec. How can this be done ?

    Looking forward.
    Dave Mac

    It's not so much what you don't know that gets you into trouble, but what you know for sure, that just ain't so. - Mark Twain.

  6. #6
    "Certified" Alphaholic Ted Giles's Avatar
    Real Name
    Ted Giles
    Join Date
    Aug 2000
    Location
    In the Wolds, Louth, Lincolnshire, UK
    Posts
    4,358

    Default Re: Table Open Table structure

    Dave, not a Prophesy but a Prediction.
    Your naming conventions will bite you in the bum in the near future.
    Ted Giles
    Example Consulting - UK
    .

    http://ec12.example-software.com//
    See our site for Alpha Support, Conversion and Upgrade.

  7. #7
    Member
    Real Name
    Dave Mac Callum
    Join Date
    Jan 2006
    Location
    Johannesburg. South Africa
    Posts
    383

    Default Re: Table Open Table structure

    Quote Originally Posted by Ted Giles View Post
    Dave, not a Prophesy but a Prediction.
    Your naming conventions will bite you in the bum in the near future.
    Hi Ted,

    Thanks for the warning.

    What do I need to attend to before the bus falls off the cliff ?

    Looking forward
    Dave Mac

    It's not so much what you don't know that gets you into trouble, but what you know for sure, that just ain't so. - Mark Twain.

  8. #8
    "Certified" Alphaholic Ted Giles's Avatar
    Real Name
    Ted Giles
    Join Date
    Aug 2000
    Location
    In the Wolds, Louth, Lincolnshire, UK
    Posts
    4,358

    Default Re: Table Open Table structure

    "sop_items_head_inv_this_some_of_that" would be an example.

    The length of the variable will cause you some confusion in the future. I realise why you are doing it - however you might want to think of a way of simplifying matters.

    If you are happy with the complexity and will be supporting this app all well and good.
    I had to follow a Cobol programmer (my bum) who used the most longwinded approach I have ever come across. It took weeks to unravel what should have been a simple job.
    Your app, your call.
    Ted Giles
    Example Consulting - UK
    .

    http://ec12.example-software.com//
    See our site for Alpha Support, Conversion and Upgrade.

  9. #9
    Member
    Real Name
    Dave Mac Callum
    Join Date
    Jan 2006
    Location
    Johannesburg. South Africa
    Posts
    383

    Default Re: Table Open Table structure

    Hi Ted,

    I enclose a screen dump of the variables that I am using. I see that the longest is 17 chars, although my aver var is less than 10 chars.

    The 's_head_prep' is a table name. Should these be shorter ?

    Be aware that the 'Prep Parent' column of 'Params_tnm_b' holds the name of tables

    I need to understand before casually going down the wrong road. Maybe you can give me an example of what I need to change

    Thanks,

    Looking forward
    Attached Images Attached Images
    Dave Mac

    It's not so much what you don't know that gets you into trouble, but what you know for sure, that just ain't so. - Mark Twain.

  10. #10
    "Certified" Alphaholic Mike Wilson's Avatar
    Real Name
    mike wilson
    Join Date
    Apr 2005
    Location
    Grand Rapids, Michigan
    Posts
    4,198

    Default Re: Table Open Table structure

    Code:
    Apologies for not giving you the complete story. Mike, I will see if i can cut and paste code to you...
    Sorry, not able to see how I can select where to paste my code to you - can you advise (one of the above icons? )
    Highlight and Ctrl-C, or Alt-A then Ctrl-C the code in the Code Editor and paste it into the message board window. With code highlighted use the # icon ablove the message board window.
    Mike W
    __________________________
    "I rebel in at least small things to express to the world that I have not completely surrendered"

  11. #11
    "Certified" Alphaholic Ted Giles's Avatar
    Real Name
    Ted Giles
    Join Date
    Aug 2000
    Location
    In the Wolds, Louth, Lincolnshire, UK
    Posts
    4,358

    Default Re: Table Open Table structure

    Dave, I am impressed with the comments in the code. MOST professional.
    There is a theory that the Field Names are 10 or less. I guess that Table names can be as long as you like, however the simpler the better.
    I'd probably avoid too similar names, but that's a personal preference to name them for their intended purpose. e.g. Demograph, Invoice, InvHead, InvDet etc.
    I have had a few seemingly random problems with Alpha Indexing (V9) where the first 6 chars of the field name were the same.
    You may have the same with Variables - especially if you pick up the wrong one in a dropdown.
    Ted Giles
    Example Consulting - UK
    .

    http://ec12.example-software.com//
    See our site for Alpha Support, Conversion and Upgrade.

  12. #12
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

    Default Re: Table Open Table structure

    Field names don't have to be 10 or less but they will be bullet-proof if they are. Same goes for index names. The 10 character limit does not apply to any other names.

    There are limits to other names but they are all over 10. Layout names and, I believe, Operation names are limited to something like 24 characters. Table names are only limited by whatever Windows allows file names to be - which is much larger than I think they should ever be. (But there are potential issues with blank spaces in file names. See the link to my white paper below for more info.)

    If you handle your files correctly, longer names (there is a limit of something like 24 characters?) won't be an issue. But if you accidentally mess up with some file transfers it can delete all but the first 10 characters of your field and index names. (Note that this is a development issue. It's not something that will happen while your customer is using the database unless they are dumb enough or careless enough to delete files they shouldn't be deleting.)

    At the request of developers many years ago, Alpha created a way to get around the 10 character limit of DBF files. This means that the long field and index names are not part of the table itself but are instead stored in the data dictionary files. If those files get separated from the data files then you will lose your long field names. You either have to restore those data dictionaries from a backup or recreate the names yourself. In most cases, simply restoring the files from a backup will do the trick but I've seen cases where backups weren't available or were so old as to be unusable with the current table structure.

    Another thing that people should consider when using long names is that the first 10 characters are key. If you start creating long names like:
    customer_number
    customer_name_first
    customer_name_last
    customer_name_middle
    customer_name_suffix
    customer_name_prefix
    and something happens to truncate the names, you will end up with 6 names that look like this:
    customer_n
    customer_n
    customer_n
    customer_n
    customer_n
    customer_n

    If that happens and you are not aware of it, you are likely to get script errors something like "field not found". You might even get some strange warning during the "fixing" process if the Customer_Number field is numeric since all the rest of the fields are obviously character values.

    Also note that other programs that import your data from the .dbf files will not be able to pick up the long field names. For example, if you try to open a table with the fields in the example above using Excel, you will only see the "customer_n" part of the field names. In this example it's probably not too hard to figure out just be looking at the data in the fields but I've seen situations where that wasn't true. (Exporting to Excel will probably show the long field names - I'm talking about reading the .dbf file directly using any 3rd party program.)

    I personally stick to the 10 character max philosophy but I know many people that don't. And many of those people don't have any problem. However, I've had - and seen - enough problems in the past that I prefer using a method that eliminates all worries about truncating names.

    For more of my thoughts and rationale on naming issues, see this "white paper" I did a few years ago. Even if you don't agree with specific recommendations, you will at least have a better understanding of the potential issues.

    One thing that isn't addressed in that paper is the idea of avoiding the use of names that are - or should be - reserved names. I've seen that kind of thing happen a lot although I can't think of any specific examples right now other than the obvious things like built-in function names. (Maybe I'll start compiling a list of what ought to be reserved words and add it to my paper - suggestions welcome.)
    Last edited by CALocklin; 08-31-2011 at 06:24 PM.

  13. #13
    "Certified" Alphaholic DaveM's Avatar
    Real Name
    Dave Mason
    Join Date
    Jul 2000
    Location
    Hudson, FL
    Posts
    6,022

    Default Re: Table Open Table structure

    I generally stick to the old 8.3 dos naming of any files and 10 or less for everything else except variables and I try to stay under 12 with them. It does simplify most things I do or when I have to go back into it later.

    Remember the old days when more than 8 of anything was very bad and got worse. That is the era I came from and it is hard to change spots.
    Dave Mason
    dave@aldausa.com
    Skype is dave.mason46

  14. #14
    Member
    Real Name
    Dave Mac Callum
    Join Date
    Jan 2006
    Location
    Johannesburg. South Africa
    Posts
    383

    Default Re: Table Open Table structure

    Thanks for the input Guys. Cal, I need to go back to many of my tables and clean them up. Are you reasonably sure that Alpha5 directories are able to manage with all field and file name changes that are made without going up the wall ?

    With your Aims program that I use, it occurred to me that if your program can locate all occurrences of 'Trade_transactions' (which it does), can it not go a step further and alter all those located to 'Trde_xact' ?

    Looking forward
    Dave Mac

    It's not so much what you don't know that gets you into trouble, but what you know for sure, that just ain't so. - Mark Twain.

  15. #15
    "Certified" Alphaholic Ted Giles's Avatar
    Real Name
    Ted Giles
    Join Date
    Aug 2000
    Location
    In the Wolds, Louth, Lincolnshire, UK
    Posts
    4,358

    Default Re: Table Open Table structure

    Dave,
    If it was my problem, I'd replicate what you have and change the replica.
    The trouble with the copy routine is that you will - if chosen - get duplicate Forms.
    You might be better off copying the whole database folder to a new one and working on that.
    How many Tables and associated Forms will you need to change?
    If you truncate, as has been commented upon, you will find it easier to follow the logic of the Forms and
    Scripts.
    Ted Giles
    Example Consulting - UK
    .

    http://ec12.example-software.com//
    See our site for Alpha Support, Conversion and Upgrade.

  16. #16
    Member
    Real Name
    Dave Mac Callum
    Join Date
    Jan 2006
    Location
    Johannesburg. South Africa
    Posts
    383

    Default Re: Table Open Table structure

    Quote Originally Posted by Mike Wilson View Post
    Code:
    Apologies for not giving you the complete story. Mike, I will see if i can cut and paste code to you...
    Sorry, not able to see how I can select where to paste my code to you - can you advise (one of the above icons? )
    Highlight and Ctrl-C, or Alt-A then Ctrl-C the code in the Code Editor and paste it into the message board window. With code highlighted use the # icon ablove the message board window.
    Mike,

    Thanks for the pointer. Works well

    Have a good one
    Dave Mac

    It's not so much what you don't know that gets you into trouble, but what you know for sure, that just ain't so. - Mark Twain.

  17. #17
    Member
    Real Name
    Dave Mac Callum
    Join Date
    Jan 2006
    Location
    Johannesburg. South Africa
    Posts
    383

    Default Re: Table Open Table structure

    Quote Originally Posted by Ted Giles View Post
    Dave,
    If it was my problem, I'd replicate what you have and change the replica.
    The trouble with the copy routine is that you will - if chosen - get duplicate Forms.
    You might be better off copying the whole database folder to a new one and working on that.
    How many Tables and associated Forms will you need to change?
    If you truncate, as has been commented upon, you will find it easier to follow the logic of the Forms and
    Scripts.
    Hi Ted,

    Replicate seems a good idea. I have quite a few changes to do. Get a load of attached debt.jpeg, and you can see what a problem I have here. Field structure, which follows Cal's recommendation should be more like attached dbt.jpeg, except that the table name if way too long and cumbersome.

    Problem being that I am still developing and there could well be changes as I go. Customers breathing down my neck steers me in a direction of completing what I have and then going back. Problem there is that the road back becomes longer every development day. One thing about this scenario is that I haven't been board since I don't know when.

    Have a good one
    Dave Mac

    It's not so much what you don't know that gets you into trouble, but what you know for sure, that just ain't so. - Mark Twain.

  18. #18
    Member
    Real Name
    Dave Mac Callum
    Join Date
    Jan 2006
    Location
    Johannesburg. South Africa
    Posts
    383

    Default Re: Table Open Table structure

    Hi Ted,

    I left the attachments behind.

    Here the are.
    Attached Images Attached Images
    Dave Mac

    It's not so much what you don't know that gets you into trouble, but what you know for sure, that just ain't so. - Mark Twain.

  19. #19
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

    Default Re: Table Open Table structure

    Quote Originally Posted by Dave Mac Callum View Post
    Thanks for the input Guys. Cal, I need to go back to many of my tables and clean them up. Are you reasonably sure that Alpha5 directories are able to manage with all field and file name changes that are made without going up the wall ?

    With your Aims program that I use, it occurred to me that if your program can locate all occurrences of 'Trade_transactions' (which it does), can it not go a step further and alter all those located to 'Trde_xact' ?

    Looking forward
    I need to go back to many of my tables and clean them up.

    1. My general philosophy is, "Don't change it if it ain't broke." Assuming your application is pretty much finished and there are a lot of scripts and expressions to be changed, cutting long names to 10 chars or less just because they are long names may cause more problems than it will fix. It will probably also take more time than it's worth. If you are just beginning the app, then I'd consider changing the names. Obviously there's an "in between" but I'll leave it up to you decide where that is.

    2. I thought about adding the ability to automatically replace text. Then I thought about how many times I'd used similar features in other programs and ended up accidentally changing things that I didn't want to change - and I opted not to add that feature. (Besides, it would be a LOT of work to add that feature. The search routine is searching through my "documentation" table - updating that would be easy. However, to make changes in your application I'd have to figure out where that code was located then open the appropriate script/function or data dictionary and edit it and the method for editing would depend on where it is.)

    Are you reasonably sure that Alpha5 directories are able to manage with all field and file name changes that are made without going up the wall?
    Yes. But ...

    Field names:

    First, I agree with the other comments - make the changes in a copy of the app or at least have a backup ready.

    Changing field names in the table should work fine - even if you change every name before saving changes. What I would be careful of is changing names and field sequences at the same time. I've had problems with this in the distant past if I tried to do too much. It may work fine today and it may even have been my fault in the past (although I don't think so) but I am now much more cautious about how many changes I make before saving the changes and verifying them. I try to take it in steps. I might change all the names, save the changes, then change the location (sequence) of a few fields (5? 10?) and save the changes before relocating a few more. How many depends on how complex the moves. If I was moving 10 fields all to the top of the list, I'd probably do them all. If I was moving one field down 10, one field up 5, and one in between the other two, I might just move the first two and save before moving the last. In one post a long time ago I made the comment that if I'm starting to get even slightly confused about what changes I've made then it's time to save the changes in case A5 is "getting confused" also. At the very least, this will minimize the number of things that you have to fix - no matter what/who caused the error.

    Of course, changing the names in the scripts, functions, and expressions all at once is no problem unless you miss some or misspell some. This is one reason why I usually don't make field/index name changes on completed apps. The other reason is that it just isn't worth the time required. The only time I would be sure to make a field/index name change on a completed app is when the name is causing confusion during debugging/updating or, perhaps, if it's the same as a reserved word. (A5 has an official list of reserved words in their Help file but there are others I'd also be careful about using if for no other reason than to avoid confusion when debugging or updating. In general, my philosophy of using 2-word names pretty much avoids this problem so I can't think of any specific examples right now.)

  20. #20
    "Certified" Alphaholic Ted Giles's Avatar
    Real Name
    Ted Giles
    Join Date
    Aug 2000
    Location
    In the Wolds, Louth, Lincolnshire, UK
    Posts
    4,358

    Default Re: Table Open Table structure

    Quote Originally Posted by CALocklin View Post
    I need to go back to many of my tables and clean them up.
    Field names:
    What I would be careful of is changing names and field sequences at the same time. Well pointed out. Do regular saves if you choose this route..
    )
    Didn't realise you were up to your backside in alligators Dave. As CAL says, it might be as well to slug it out with the format you have and sell 'em an upgrade later!
    What you have will probably work as it seems that the first chars are unique.
    Have a look in the database Design section for an embryonic Data Dictionary (Misspelled BTW). Might helpyou.
    http://msgboard.alphasoftware.com/al...t-DD-iteration.
    Last edited by Ted Giles; 09-01-2011 at 04:22 PM.
    Ted Giles
    Example Consulting - UK
    .

    http://ec12.example-software.com//
    See our site for Alpha Support, Conversion and Upgrade.

  21. #21
    "Certified" Alphaholic DaveM's Avatar
    Real Name
    Dave Mason
    Join Date
    Jul 2000
    Location
    Hudson, FL
    Posts
    6,022

    Default Re: Table Open Table structure

    If it was my problem, I'd replicate what you have and change the replica.
    The trouble with the copy routine is that you will - if chosen - get duplicate Forms.
    I have had to delete a few duplicate forms, reports, etc in the past. I have also move fields in the database up or down in the distant past. I also had problems with that mostly in the form of messed up field rules. If adding fields, do so at the bottom. It may or may not matter, but I won't take the chance anymore.

    If adding fields in an update later, I do this with a temp adb that attaches a table or more. Once the adb is run one time, it is destroyed and the app(on start juast has added fields to a table or two and the associated files have been changed to accomodate them.

    Code:
    'this is actual code and it works, there are other functions to change the type of field and to make it longer, shorter, etc
    fields = <<%str%
    tankgals,n,2,0
    minleftpct,n,2,0
    maxleftpct,n,2,0
    Rearmin,n,8,3
    Rearmax,n,8,3
    Mindiag,n,8,3
    Maxdiag,n,8,3
    %str%
    table.add_fields("cars", fields)
    Dave Mason
    dave@aldausa.com
    Skype is dave.mason46

  22. #22
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

    Default Re: Table Open Table structure

    Quote Originally Posted by DaveM View Post
    ... I do this with a temp adb that attaches a table or more. Once the adb is run one time, it is destroyed ...
    That works fine - one time.

    But what happens if, as I've had happen a few times now, someone restores backup data from before my update? An error will be generated if any scripts, field rules, etc. are expecting the new fields.

    I use a function I call Add_update_fields() that will add the missing fields no matter how far back the data is restored. The function runs every time the application starts (i.e., it's called from the autoexec script) and checks for the last field that was added. If the last field added already does exist, the routine ends in just a few milliseconds. If that last field doesn't exist, ALL fields added since day 1 are checked and added in the same sequence they were originally added. (The field check is done one table at a time since the only sequence that is important is the sequence within each table.) If fields are only added and not updated, the 'addition' occurs very quickly. The speed of updating field values, of course, will depend on how many records there are and how complex the update is.

    One thing that most people seem to have a hard time grasping is that the data dictionary can have 25 fields "defined" while the actual table only has 20. This is what happens when an update is being installed or an old backup is restored - the existing data doesn't have the new fields yet but the data dictionaries do. The next time the application is started the add_update_fields() runs and adds the missing fields so that now the table and the data dictionaries match again. NOTE: This ONLY works if all new fields are always added at the bottom of the list - which, by the way, is the only way it can be done when using the a5_add_fields_to_table() command.

    The above paragraph may need some explanation. When I send an update to my customers, it NEVER includes a copy of their data. It only includes the data dictionary files and the .adb file. I rely completely on the Add_update_fields() to handle any field additions/changes necessary. Restoring an old backup does essentially the same thing as an update - an update is installing new data dictionaries with existing data whereas restoring an old backup puts old data with the "newer" (current) data dictionaries. In either case, "old" data exists with "newer" data dictionaries and the add_update_fields() function updates the old data structure so it will work correctly with the newer data dictionaries.

    I'm sure I've posted examples before but I'll attach an example that shows how to add fields, change existing structure, and update new fields. Note that new fields are ALWAYS added at the end of the table. (This is a shortened version of the actual function used in one of my applications. The actual function in that app is over 900 lines and growing - I've added a lot of features to this app.)

    I've been using this method for 10 years and the only situation I've found where I won't use it is for deleting fields - so I just don't delete fields even if they aren't needed anymore. If the field was a really large one, I'd probably change the structure so it was smaller but I don't think I've "deleted" more than 1 or 2 fields in all that time and they weren't very large so I just ignore them. The fields can be deleted with the a5_del_fields_fm_table() command but it can be rather dicey if someone restores old data without re-running the autoexec because the deleted field won't be deleted yet and it can make a real mess of things if the user starts trying to work with the data or, worse yet, "fix" it. In that case, the wrong data will appear in any field listed after the field that was supposed to be deleted. Similar issues can occur if someone installs an update without restarting the app - including restarting it on all workstations. (There is one situation were I used the a5_del_fields_fm_table() command but that was only because it was used so shortly after adding the field by mistake that I was confident that no other fields would be added first and cause the issues described above. See the example.)

    EDIT: After writing this and re-reading your post, I'm not sure what you mean by "I do this with a temp adb". I initially took it that you were including an updated table and importing the data from the old table then deleting the old table and renaming the new table. I know a number of people have done something like that but now I'm not so sure that's what you are doing.
    Attached Files Attached Files
    Last edited by CALocklin; 09-06-2011 at 04:10 AM.

  23. #23
    "Certified" Alphaholic Ted Giles's Avatar
    Real Name
    Ted Giles
    Join Date
    Aug 2000
    Location
    In the Wolds, Louth, Lincolnshire, UK
    Posts
    4,358

    Default Re: Table Open Table structure

    This looks like a very handy piece of code.
    Can I use it CAL?
    Ted Giles
    Example Consulting - UK
    .

    http://ec12.example-software.com//
    See our site for Alpha Support, Conversion and Upgrade.

  24. #24
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

    Default Re: Table Open Table structure

    Quote Originally Posted by Ted Giles View Post
    This looks like a very handy piece of code.
    Can I use it CAL?
    Not a good idea - it probably wouldn't work very well as-is.

    But, yes, feel free to use it as a guide/template to create your own. That's why I posted it.

  25. #25
    Member
    Real Name
    Dave Mac Callum
    Join Date
    Jan 2006
    Location
    Johannesburg. South Africa
    Posts
    383

    Default Re: Table Open Table structure

    Hi Dave and Cal,

    Thanks for your pointers. I have this application which is parameter driven and is the basis of most of my apps. So, I need to straighten it out rather than have problems further down the road. So even if 'it's not broke' I need to fix it, although it hurts to spend the time on it.

    Have a good one
    Dave Mac

    It's not so much what you don't know that gets you into trouble, but what you know for sure, that just ain't so. - Mark Twain.

  26. #26
    "Certified" Alphaholic DaveM's Avatar
    Real Name
    Dave Mason
    Join Date
    Jul 2000
    Location
    Hudson, FL
    Posts
    6,022

    Default Re: Table Open Table structure

    Yes. Pain in the a... now, but I can assure you the pain down the road is almost like going to the hospital for a rectal operation.
    Dave Mason
    dave@aldausa.com
    Skype is dave.mason46

  27. #27
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default Re: Table Open Table structure

    This is an aging thread, but there is a trick that I'd like to share: Duplicating sets & forms, renaming them, and then dropping the originals. If you duplicate a set or table, you can then drop this duplicate from the database (when you first duplicate it, append the new set/table name with either version, or date).


    • The neat thing is that once dropped, you have a complete backup including their associated forms, browses, reports, etc.... (which are now dropped from the database ie: not seen in the control panel, yet may be restored at a later point. (and then renamed back to the original set / file names)
    • The coolest thing is that dropping the sets (and tables) also drop all the duplicate forms, browses, and reports etc. (So you don't end up with duplicates.) ~ And these dropped "companion" objects maintain their original names, even though the tables / sets were appended with versioning info.
    • The one BAD thing about using this method is none of the backup routines in Alpha backup these dropped objects.* (So you can't expect to recover them if you use the built in backup / zip options.)



    *The solution to this is to backup / zip the entire database (with sub-directories) using a third party zipping tool. (Or even the one built into windows) With this approach, you have everything, and will never worry about making irreversible changes. If you routinely backup sets & forms (duplicate/rename & drop) like this, you also protect yourself with backups of forms in the event they ever become corrupt beyond repair. (I've never experienced this, but years gone by, I've read about it here.)


    Note: Scripts (before editing / changing) in the code tab still have to be backed up somehow, because dropping tables has no effect on items in the code tabs.

    PS: Another thing that might help while working with live versus non-live data could be the use of aliases in system settings. (I haven't worked with them yet though.)
    Last edited by SNusa; 02-01-2012 at 01:25 AM.
    Robert T. ~ "I enjoy manipulating data... just not my data."
    It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
    RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

  28. #28
    Volunteer Moderator Peter.Greulich's Avatar
    Real Name
    Peter Greulich
    Join Date
    Apr 2000
    Location
    Boston, MA
    Posts
    11,643

    Default Re: Table Open Table structure

    Quote Originally Posted by SNusa View Post
    Note: Scripts (before editing / changing) in the code tab still have to be backed up somehow, because dropping tables has no effect on items in the code tabs.
    Not exactly sure what you mean, but scripts, etc are stored in the databaseName.alm/alx/alb files

  29. #29
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default Re: Table Open Table structure

    Peter;

    The duplication "method" I mentioned above backs up all the associated layouts (forms, browses, letters, reports, and even labels I believe). ~ But it doesn't do anything with objects in the code tab. (So by duplicating and dropping, there is no backup of your scripts.)

    Hence, if you restore (add the table/set back in, delete the previous version, and rename the re-added table/set back to it's original name) you have the previous version back and working with the exception of everything on the code tab. Your scripts and everything there is the the most recent stuff, as none of it is stored with dropped tables.)

    TRY THIS WITH AN EXAMPLE DATABASE:


    First look through the tabs on the control panel.
    Next, duplicate a table or set. (when you duplicate it, rename it by adding a version. ie: customers becomes customers_v1, or customers_20120201)
    Look at all the tabs. ~now evertything is duplicated except the stuff on the code tab.
    Now, drop this newly duplicated table.
    Here's the fun part: totally screw up your database by messing with the forms, messing with the layouts and browses associated with the table (or set) you previously deleted........ Now your database is totally broken........ and it's time for a quick restoration...... (A scenario where you have to go way back to a previous starting point)

    Simply, delete the original table or set, and take notice of the name of this table/set. (depending upon what you chose to originally duplicate)
    Now, add the backup (previously dropped table/set)
    Last, rename this table (or set) back to customers. (In my example, "customers_v1" or "customers_20120201" gets named back to simply customers.)


    VOILA - Everything is now restored & working. Except for everything in the code tab. (dropping and restoring tables /sets has no effect on your scripts, or any other objects within the code tab. ~ If you changed or messed up scripts, menus, toolbars, functions etc.... You still have the most current version of them.)

    I guess, in essence you're saying the same thing that I 'm saying: In that the scripts, etc are stored separately. This trick is just an interesting way of "versioning" that keeps the old stuff fully intact and available, in the even you need to "hit the reset button" if things get messed up. (And using this method keeps everything (on all the other tabs) together by just focusing on dropping and adding tables/sets.

    NOTE: If you're using live .dbf data, you obviously don't want to be re-adding tables because of their associated .dbf files are old. But as for the sets, this still works nicely! This works great for one of those scenarios where you have something that works very nicely, but you want to try something different using what already works. If it doesn't, you can quickly "bounce back" to what worked and try again. (Regardless, this makes for a great "hidden backup" that can be contained (out of the way) within the database directory/container.) ~ AWESOME TECHNIQUE FOR LEARNING....

    I was using it for sets and not tables, and I was renaming sets to set_v01, set_v02 etc, by simply copying the original set and dropping the previous version that worked. (But I later realized I could do this with tables too, if the dropped tables & sets contained the "versioning" suffix instead. Plus, I have since learned that there are instances where a5 code uses a set name, and when it does, the renaming of sets in use would have caused problems.

    So in a nutshell: To backup a complete set or table (with all it's layouts, browses and operations etc, except for associated code tab objects) all you have to do is:


    1.) Duplicate it (and name this new duplicate using the original name + version info) and...
    2.) Drop it. ~ Instant recover is in place, and you never have to look at it again, if & until you need it!

    Just remember to backup your scripts too in case you need to rollback.
    (And don't rely on the built in zip / backup routine to backup these dropped tables, because they don't, and unfortunately there is no checkbox setting for this.)
    Robert T. ~ "I enjoy manipulating data... just not my data."
    It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
    RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

  30. #30
    "Certified" Alphaholic DaveM's Avatar
    Real Name
    Dave Mason
    Join Date
    Jul 2000
    Location
    Hudson, FL
    Posts
    6,022

    Default Re: Table Open Table structure

    Robert,

    you may want to check your naming of tables, fields, forms, etc. I for one, desperately try to keep everything to 8 letters and maybe 10 on some stuff. There is(or at least was) a problem with names getting shortened by the system sometimes.
    Dave Mason
    dave@aldausa.com
    Skype is dave.mason46

Similar Threads

  1. Trying to update structure of table
    By markusjd in forum Alpha Five Version 5
    Replies: 16
    Last Post: 03-23-2007, 12:46 PM
  2. Import table structure
    By Al Buchholz in forum Archived Wishlist
    Replies: 0
    Last Post: 10-17-2005, 08:26 PM
  3. table structure changes
    By Sonia Sidhwaney in forum Web Application Server v6
    Replies: 3
    Last Post: 06-29-2005, 03:20 AM
  4. display table structure
    By Michaela Koblitzek in forum Alpha Five Version 4
    Replies: 6
    Last Post: 07-04-2001, 08:29 AM

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
  •