Sharing same dbfs with v8 and v10?

[MoGrace]

Would it be possible to put the tables into one directory on the server and the support files in different subdirectories with the adb so two shadow versions of Alpha could update the same tables from different stations? (Geesh it sounds stupid to even ask...) But I have more licenses for v8 than I do for v10.

[Stan Mathews]

Re: Sharing same dbfs with v8 and v10?

Same question as this?

[MoGrace]

Re: Sharing same dbfs with v8 and v10?

Almost the same question. They were asking about an app that didn't have any form changes. I was trying to figure out how to point to the support files, but see this wouldn't work since the tables the adb is pointing to is where it locates the support files. I knew it was a dumb question...but sometimes you gotta ask before you realize why!

I was thinking that by shadowing each app on a station, it would use the right support files at the station rather than the server. Of course how I could accomplish this would be to overwrite the server files as I made each shadow. Or something like that.

[seaken64]

Re: Sharing same dbfs with v8 and v10?

I've never been clear as to why we can "connect" to non-Alpha databases but cannot use the native format files using different versions of the A5 program.

I also would like to be able to use the native DBF files that I have developed in a A5v9 database with an application made in A5v8, or v7, whatever. But if I "add" the database file to the alternate application the DBF is not the only file affected.

Why can I "connect" to a live database from SQL but not to a live DBF file. I'm sure it has something to do with how these types of files are designed but I still don't understand why I can't use two different versions of A5 to manipulate a single DBF database file.

Sean

[MikeC]

Re: Sharing same dbfs with v8 and v10?

Sean,

I must be misunderstanding something here....I can open any Alpha application/project with any version of Alpha at the same time and modify the data in the same table--opened at the same time......and be entering in a record (not saved) in one Alpha and enter in a record in the other at the same time......

This is something that also is dependent upon if both versions of Alpha can "read" the code...that is that one version is not using a feature or function that is version specific.

What exactly is the issue???

[seaken64]

Re: Sharing same dbfs with v8 and v10?

Sean,

I must be misunderstanding something here....I can open any Alpha application/project with any version of Alpha at the same time and modify the data in the same table--opened at the same time......and be entering in a record (not saved) in one Alpha and enter in a record in the other at the same time......

This is something that also is dependent upon if both versions of Alpha can "read" the code...that is that one version is not using a feature or function that is version specific.

What exactly is the issue???

Hi Mike,

Honestly, I'm not really sure. I'm not very clear on the relationships between the DBF files and the A5 applications that use them. I have asked about this several times in the past and was always directed to stay away from using the same DBF files (Tables) in different Applications using different versions of A5.

Apparently A5 does not just read and write to the DBF file but adds other files and makes changes to files that may be used by the other versions? Believe me, I don't understand all of this so I may be way off base here. I you are telling me that I can use the same DBF files with multiple applications from multiple versions of A5 I will gladly start pursuing this on my LAN. I have avoided doing this so that I don't mess up my data.

Sean

[Stan Mathews]

Re: Sharing same dbfs with v8 and v10?

Apparently A5 does not just read and write to the DBF file but adds other files and makes changes to files that may be used by the other versions?

In any version of Alpha you use create a new table - no field rules, no indexes, just plain. Use your favorite file manager and view the directory in which you created the table. You will find the .dbf and the corresponding .ddm, .ddx, and .ddd that Alpha has prepared to hold any layouts you create.

These support files can be used by multiple versions. I open many of the samples posted on this board in V5 or V8 with few problems.

Should you happen to build a form, for instance, using a feature made available in V10.5 and thus does not exist in V8, what would you expect to happen when you opened the form in V8? Should you happen to modify a form created in V8 with the same feature, same problem.

If you edit the field rules for a table incorporating a function in xbasic that didn't exist in an earlier version and then opened it in that earlier version?

[Tom Henkel]

Re: Sharing same dbfs with v8 and v10?

My main systems are written in ver 5. We are converting to and testing ver 10.5. We have one small isolated app written in ver 8 that runs along side and using tables in the main ver 5 apps. We needed ver 8 for an active-X component. These systems have been running nicely for a number of years now. The biggest thing you need to do is to keep things straight. I do NOT modify any dictionary files with the Ver 8 software. Ver 5 will not accept that.

Just remember to keep things clean and simple, and you can share tables, etc. between versions.

Tom

[MoGrace]

Re: Sharing same dbfs with v8 and v10?

Well I can see that what I wanted to do isn't going to work, because I have made changes in v10. So if I want to put the files on the server for v8 users I guess I can copy over JUST the dbf files so the most current data is there and that should leave the original v8 support files unchanged. Then I can use either v10 or v8 to view those files but will not have any of my new forms available for me to use. Phooey...

I suppose I could just zip the files and copy them to my own station and then back to the server to update them.

Or I could cut loose with some change and buy a few runtimes...

[Stan Mathews]

Re: Sharing same dbfs with v8 and v10?

I can copy over JUST the dbf files so the most current data is there

Yeah but, you'll need to reindex all tables (with indexes) after you copy the dbf files to a new location.

[MikeC]

Re: Sharing same dbfs with v8 and v10?

Hi Robin,

but will not have any of my new forms available for me to use

This is the key really....Most forms will display and act nice when viewing a v10 form with v8 or v9....you will know right away if they do not.

But if you do (or anyone really), be aware that if there are action scripts contained in whatever, they will be "regenerated" by each version...and there are some (which???) that have subtle differences and you could mess things up. If, however, you have all xbasic code, then this is not a worry.

[seaken64]

Re: Sharing same dbfs with v8 and v10?

So, if I put all my data in DBF files in one folder and leave them there, I can add them to any number of applications created in versions 7, 8 and 9 and as long as I have forms and other support files unique to each version of A5 I can share the DBFs?

Or will all the forms I create end up in the same folder with the DBF files? In this case I could name each form to identify the version being used to create that form so I can keep things straight.

I'm mostly interested in using a previous version (v8) in my shop where I have a separate server. My main data is on my main server in the store but I have that disk mapped as a network share in the shop. I wanted to set up some applications using my version 8 desktop developer and web server but using some of the same data tables.

I'll set up some tests to see if this will work.

Thanks,
Sean

[Tim Kiebert]

Re: Sharing same dbfs with v8 and v10?

The layout definitions are stored in those 'other files'. For tables; DDD,DDM, DDX and for sets; SEM, SET, SEX. You could just make separate layouts for v8 but I would go one step further and make separate sets. That way if you edit layouts in v10 you won't even be writing to a dictionary that may have a v8 form in it. Sets take up very little room as all they contain is linking information. (and any attached layouts.) So you could have v8 set and a v10 set holding their respective layouts but using the same tables.

Do you have forms against just one table? No matter, you can create sets that only contain one (ie the parent) table.

Now you have a lot of the functionality isolated away from the tables. As Stan mentioned it is still possible to use later more advanced features in the field rules and even in expressions in indexes so watch out for that.
I would recommend that you still keep all these tables and sets in one folder.

Another option is with all the cheap deals going these days get your self a runtime license and you might make the cost back in saved time. ;)

[Peter.Greulich]

Re: Sharing same dbfs with v8 and v10?

Or to state what Tim said another way, you could make a unique application for v7,8,9,10 - each app with their own forms, sets, whatever - all sharing the same tables.

- OR -

you could build a single v10 web/browser app and publish it to your LAN and everyone on your network accesses it through their browser (I know, this is heresy in the desktop world - just a thought).